W3C

- DRAFT -

Social Web Working Group Teleconference

23 Sep 2016

See also: IRC log

Attendees

Present

rhiaro, cwebber, tantek, KjetilK, aaronpk, tsyesika, Benjamin_Young, csarven, newton, Arnaud, Ann, Bassetti, AnnBass, ben_thatmustbeme, david_wood, eprodrom, wseltzer

Regrets
Chair

tantek

Scribe

AnnBass, rhiaro, aaronpk, cwebber2

---

Minutes

Scheduling

Tantek: begin with agenda scheduling

cwebber2 shows mediagoblin video

applicable to social web concepts

<cwebber2> http://mediagoblin.org/pages/campaign.html

decentralized ... federated ...

<discussion about the MediaGoblin fundraising campaign>

tantek: <agenda review>
... assuming we get through the agenda as listed, afternoon is open

<cwebber2> https://www.w3.org/wiki/Socialwg/2016-09-22

<Loqi> Social Web WG Face to Face Meeting in Lisbon (F2F7)

tantek: any other suggestions / edits / ?

sandro: <timing for Evan to come online>
... we had scheduled for 1:00pm Lisbon, 8:00am ? Evan's time ... may want an hour later
... hoping Evan will let us know before we go to lunch

tantek: left off with ActivityPub open issues

ActivityPub continued

cwebber2: "source" field 107
... sugg putting a note in there
... your source has warning that if you edit this, you'll lose your previous source

rhiaro: yesterday it felt like blocking the user, but this seems like a warning

cwebber2: adds source, provides info for user to know what to do

tantek: what about server choosing what's canonical?

aaronpk: I wouldn't do it that way, but i'm not going to try to convince you to change to the other model. however this doesn't feel like it's been fully thought out all the way through

cwebber2: I'd like to use this period to try this out, see if we can figure it out

tantek: you have implementation experience?

cwebber2: we've seen other pumpio implementations ...
... tsyesika sugg we include history, but now we think that makes it too complicated

sandro: I'm hesitant about the Note only being informative .. esp if user is going to lose source

cwebber2: I'm hesitant to specify a UI when it might be improved

sandro: is there an idea about ActivityPub UI?

cwebber2: partially, "conformant client" ... could do this as "should"; don't think it should be "must"

rhiaro: what about doing something on server?

sandro: I"m cool with "should"

cwebber2: <edits comment in github>

<rhiaro> scribenick: rhiaro

PROPOSAL: Add source field to AP as at risk per proposal in activitypub/issues/107

tantek: There were no objections

RESOLUTION: Add source field to AP as at risk per proposal in activitypub/issues/107

cwebber2: 106 is something I could do on my own but i wanted to get some clarity about testing requirements
... Testing servers is pretty clear to me. I can write a client that hits a bunch of URLs and does things
... Testing clients is a lot trickier

sandro: is that a validator?

cwebber2: I'm trying to figure it out..

tantek: you don't have to figure it out right now

cwebber2: I think the general plan is since there are a billion different systesm we can't touch UIs. We don't know the platform, we can't touch all those toolkits. What we can do is provide some sort of lightweight server that a client connects to, you get some prompts about the actiosn you were supposed to do and it asks you whether or not the expected behaviour happens

aaronpk: if it's like micropub where most of the spec is around CUD posts, my plan was to create a reference server that behaves the way that I expect a server to behave and have a bunch of tests that, eg. tell the client to create a post with these properties, to run it however they want to run it no under your control
... on the serverside you can check did these properties come through
... you tell the user your client needs to blah, and the server can check

tantek: can you write that down for micropub
... it's in CR, your test suite plan is up but not that level of detail

csarven: We're doing this as well, do you throw an error as to where they failed or what they should do?

aaronpk: I did a lot of error rpeoritng with webmention in very fine detail in a way I would not do in a live implementation
... REsponses come back with here is exactly where you failed
... I'd do the same with micropub

tantek: aaronpk said you would have a couple of tests for mp by october 4, canyou include this elvel of detail in your plan for how to do the tests?
... Sounds like you have thought about it, I didn't hear chris object to the methodology

cwebber2: I think it's a good idea
... I'm going to record it here

aaronpk: sure

sandro: so this is to clients

cwebber2: yes

tantek: when do you think you can have your tes tplan written up?

cwebber2: It's not the full test plan...

sandro: what do you mean by a test plan?

tantek: what is your approach?

cwebber2: I think I can have a general here's what we're planning on doing?

tantek: it can be in or outside the spec, I want a date

cwebber2: by next meeting or the one after

tantek: so the 4th
... for a general plan to the level of micropub.rocks

<aaronpk> https://github.com/aaronpk/micropub.rocks

<aaronpk> https://micropub.rocks/

tantek: if you can add more detail like you were just discussing, that's even better
... that's not a must have

sandro: would be nice if the prompts to the extent possible were the same..

tantek: general coodrination sounds like a good thing between cwebber2 and aaronpk

cwebber2: and can coordinate with rhiaro and csarven about LDN
... That wraps up this whole thing, we can do things closely

sandro: the server tests have to have ??
... you need another server the server can federate to

aaronpk: yes... webmention does that

cwebber2: checking another server is behaving correctly was easy to figure it, it was just when you can't touch the client I was struggling with

<aaronpk> https://github.com/aaronpk/micropub.rocks/issues/40

sandro: It was nice to imagine micropub and activitypub clients can test both..

cwebber2: That's the test *plan*, not the tests?

tantek: Correct
... So we can have everything in place to go to CR

sandro: I always thought you should have at least one test working... we don' thave to do that now. THe bar is technically test plan

tantek: He can work on that while we're dealing with transition call stuff
... I'd like for us to be able to propose to the group asap

cwebber2: I know how intense these few months are gonna be, I'm going to be starting tests as soon as I can
... One reason I wrote pubstrate this way was to be the basis for something like this

sandro: CR is you're telling the world please try to implement this. If you tell me it's ready to implement I'm gonna say I'll wait til I have the test suite before I implement. I like test driven development.

tantek: That's your feedback as a propsective developer
... With mp we entered CR with how many implmentations?

aaronpk: A dozen clients, handful of servers
... Emprirical testing with each other

cwebber2: It would be great if we end up doing it

sandro: micropub is trivial compared

cwebber2: There's one issue left, needs process help
... 30 JSON-LD context
... I need to test it more to make sure it expands correctly

tantek: is this beyond the context for as2?

<sandro> s/compared to the first W3C spec I implemented (OWL Full) so my perspective may be a bit different to the first W3C spec I implemented (OWL Full) so my perspective may be a bit different/

cwebber2: We have a a few additional things
... We have an inbox endoint, outbox, followers, following, they're not defined in AS2 because they're applicable to APIs which talk to each other
... So ours imports the AS2 context, so you only need to put one on there
... Maybe if the namespaces thing turns out we can put it in AS2
... I would be totally happy to have it in AS2. I'ts likely to hit rec before AP does
... Putting it in the AS2 spec would require another CR

tantek: putting in the namespace is different because AS2 is not at rec

rhiaro: I don't understand how that's different

cwebber2: If we can put this in AS2 that would simplify a lot o fthings
... I feel I need to talk to Evan and jasnell to find out what their feeling on it is

tantek: and you need to talk to sandro about the implications
... because there's not a consensus in the community about what adding to namespaces means

cwebber2: And it impacts one thing, currently we say the ld+json with profile, but having the as2 profile means it should be AP. It would be great if we didn't have that question, it would make things a lot easier if we could do things in AS2 namespace
... I've always felt this way. I just thought it wasn't possible

sandro: the whole community issue is about letting a WG defend its territory. Nobody would object if we said the AS2 ns is world writeable
... So that we can add to the ns in other specs, but also that other groups can
... I almost object to AS2 last december when we discussed CR, saying how to define the extension mechanism

tantek: there's no mechanism?

sandro: Right. The default is in the spec is use another namespace
... But that is totally messy because you have to use a bunch of namespaces, when you could just put them in if you agreed to do that
... So something with a community process that says this is okkay put it in the namespace. We couldd o that

tantek: we as a WG might not be arround, so we need to define a community process

cwebber2: I hope we find out soon what that process is

tantek: we need a resolution to this before we enter CR

cwebber2: If it's possible to get a resolution before CR great, but the reason I used our own namespace is because I thought that was unlikely
... I don't want to end up having.. it would be worse to me to be caught up trying to negotiate vocab sutff which seems to be really complex in w3c right now, than to have a separate context
... I did write up a separate context file. AP in theory works if we can put this context file somewhere. I would like us ot put it somewhere in the meanwhile, and is it possible to put it out there and then remove it?

sandro: let's try to figure this out more through the day

cwebber2: I really don't want to be blocked on CR by this

sandro: from your perspective you can say you'll use your own context..

tantek: anyone have a objection to doing it either way?
... not preferences, objection

rhiaro: If we are able to define our namespaces as writeable going forward that's awesome

arnaud: I agree with the sentiment, I just don't know how you make that happen practically

sandro: Something like the microformats process or the schema.org process
... Basically you need some benevolent dictator to manage a community that reviews and objects or doesn't object
... Since this is more under w3c... over lunch we'll figure out some..

tantek: is there an existing example of a community at w3c managing a ns that way

sandro: I don't think so

tantek: I'm hearing from arnaud a soft objection because we don't know if that could work

arnaud: I'm not objecting
... Look at the example we saw earlier with LDP. Ther'es nobody really around to say yeah sure

rhiaro: I thought we had a bunch of LDP people in the room..

cwebber2: Figuring out the extensibility of AS2 in the future is an orthoganal issue

tantek: right
... The isssue we are considering now is shall we try to add AP terms to AS2 right now
... vs shall we have a separate context for AP

sandro: Do we add it as a one time special case only we can do this, or do we add it as a first example of how to do an extension
... I'd prefer the latter

tantek: but that's not required. THere are no objections

cwebber2: I have a preference for AS2 if it's possible
... But an overriding preference to ship
... We're going to try to figure this out before we enter CR.

tantek: We have to pick a date by which we decide which we're going with
... If by then we haven't, you have a way forward

cwebber2: So the answer seems to be if we can find out we're going to put things in AS2 namespace by some date (CR date)
... Shooting for Oct 11 for CR

tantek: no objection for the same date

cwebber2: So oct 11 if we can find out by then that we can put these terms in AS2 ns, we'll do that
... If we find out then we can't, I'll put AP ns

PROPOSAL: We'll give until October 11 to find out if we can put these in AS2 vocab. If we can do that, we will. If not, I'll use AP's own namespace.

RESOLUTION: We'll give until October 11 to find out if we can put these in AS2 vocab. If we can do that, we will. If not, I'll use AP's own namespace.

rhiaro: Preference to add to AS2. Preference to make our namespaces extensible according to some sensible process (CG, W3C ns extensibility policy) in the future.

cwebber2: Preference is to add to AS2

sandro: same

tantek: anyone else want to indicate a preference on the record?

<sandro> (as the first extesion!)

sandro: My preference is to add it to AS2 as an extension

csarven: with an extensibility mechanism?

sandro: yes

cwebber2: the upside of this is that it puts pressure to resolve this within a certain period of time
... Otherwise there's a consequence of AP getting its own namespace

tantek: action on sandro to define extensibiilty model that allows AP to add to AS2

cwebber2: All issues closed

tantek: We have discussion of prototypes, implementations, at risk features
... Do you ahve changes to AP, including resolutions during last 2 days, that would benefit from publishing a new WD?

cwebber2: Someone read through it and helped me find editorial things
... fixing authz vs authn
... Something I'd like to do, this is pointed out to me with tremendous irony that I'm suggesting this, but I'd like to put the binary data stuff at risk, even though mediagoblin needs that
... Becasuse I think it might be the one thing that I'm least comfindent that other implementations that are not mediagoblin might get in on time
... I want it to happen
... But if it doesn't, it should not throw the rest of AP under the bus, because it will still work without it

tantek: There are no objections in the room

arnaud: It is good practice to explain why something is at risk in the spec

cwebber2: I'll capture that
... I notice that micropub has a much more fleshed out version of the media endpoint than we do. I took a look at ours again, and I'd like to clarify before I publish to new WD that section
... I'll look at micropub and what's happening in mediagoblin currently

tantek: do you have an issue to track that?

cwebber2: I'll add that

aaronpk: if it' snot changing the behaviour you can change the text

cwebber2: I'm not sure, I need to check it's specified enough

tantek: if it might be normative change, file an issue

cwebber2: *files issues*

tantek: Given discussion about namespaces, and that breakout yesterday, I think it would be prudent to highlight that issue inline in the spec
... where it talks about the context and the namespace
... (editorial suggestion)
... We have next steps for you to publish a new revision
... We can continue WD to CR discussion later
... or in a future telecon
... Move on to LDN

aaronpk: break?
... coffee??
... *twitches*

various: it has started

tantek: coffee?

COFFEE

• break for 20 minutes*

1030 reconvene

<KjetilK> csarven, I started a quickhack of LDN on the plane home last night: https://github.com/kjetilk/p5-rdf-linkeddata-notifications I had hoped to finish it on the plane, but the offline situation impeded the progress somewhat due to the lack of some documentation

<KjetilK> now, I'm back to proposal writing, so I don't know when I'll more hacking time

KjetlK++

<Loqi> kjetlk has 1 karma

<csarven> KjetilK: ++ Please PR to https://github.com/csarven/ldn/blob/master/implementations/readme.md

<Loqi> kjetilk has 1 karma

<KjetilK> OK!

<sandro> issue before break: https://github.com/w3c/activitystreams/issues/370

<aaronpk> scribenick: aaronpk

LDN

csarven: KjetilK who was here yesterday built an LDN receiver on the plane yesterday
... this is probably the more complicated part of the spec

rhiaro: the receiver has all the MUSTs, whereas the sender has a couple options

tantek: is it open source?

rhiaro: yes, here https://github.com/kjetilk/p5-rdf-linkeddata-notifications
... one of my colleagues implemented LDN receiving and sending in a couple days last week in Python

<KjetilK> it is just the discovery part still

<csarven> Editor's Draft: https://linkedresearch.org/ldn/

rhiaro: at the last meeting we said we'd publish a new WD and freeze this until TPAC

<csarven> Changes since last WD: https://linkedresearch.org/ldn/#change-log-Changes-from-13-September-2016-WD-to-this-version

rhiaro: we had some feedback by email and Tim
... the current ED has these changes which are largely editorial

tantek: these look great. would you like to publish this as a new WD today?

rhiaro: yes but let's do that at the end in case other things come up today
... summary of LDN. there are three parts to LDN. one is a receiver, this is like a webmention receiver. it's an endpoint that accepts POST requests from senders. it also exposes the stuff it receives so that other things can read it
... we have the capacity to add acces control so the receiver can filter what it accepts so it can do spam control for example
... the activitypub use case is you'd expect your app to authenticate to read things from the endpoint
... every existing LDP server can act as a receiver

sandro: can i try my soundbite version of this?
... in my mind, this differs from webmention in two ways. this relies on authentication so i can just send the content rather than sending a link to the content
... the second is it as the GET so you can see the content from the receiver, whereas webmention is a blind dropbox

rhiaro: it's not that it relies on authentication, it's that the verification process is up to the receiver. so you can have a publicly writable endpoint you can post to and do the verification by fetching, or you can do the verification by checking a signature, or whatever. so it handles any kind of notification payload

sandro: but if i didn't have any authentication, and if webmention had rel=mentions like ahs been brainstormed, then it seems almost equivalent to webmention

rhiaro: webmention requires you publish something at a URL whereas LDN does not

sandro: so you can send a notification from a browser, but you can't do that with webmention

bigbluehat: just to be clear. with webmention, you'd write to some write storage you have and then send that URL to the endpoint, and the endpoint would go fetch that from the URL. with LDN, either the sender can write to the inbox directly, or can still tell you about a URL.

rhiaro: yes and you can also include other information that the receiver can use to filter things out

cwebber2: to clarify the relationship between LDN and activitypub, AP says our delivery mechanism is the same. target->inbox is the same thing.

rhiaro: the mechanism is the same, but AP requires you use an activitystreams activity as the notification. LDN says you can use any payload.

tantek: okay. issues.

rhiaro: we closed a bunch of issues last week. there's a couple left open.

<csarven> https://github.com/csarven/ldn/issues/32

rhiaro: we closed #4 with agreement from sandro who opened it

<csarven> https://github.com/csarven/ldn/issues/4

rhiaro: issue 32

<csarven> Now we discuss https://github.com/csarven/ldn/issues/32

rhiaro: yesterday we talked about a backoff strategy with webmention
... webmention resolved to deal with this by adding to the user agent header
... so that someone being attacked by webmention discovery can find out what's going on
... but we have a bunch of JS considerations, where it's difficult or impossible to change the user agent in JS
... so that's not feasible for us

tantek: the problem was raised about servers talking to servers, that was the real world thing happening
... but the scope of the actual problem was specifically servers talking to servers
... but don't make the error that discovery is the problem

sandro: i think the reason is one server can hammer another without a human having a clue. whereas if a browser is happening something the browser will start being slow

csarven: they're both valid, what we're addressing here is one way of getting to it from the client, but from implementation experience it doesn't seem necessary for arbitrary user agents

bigbluehat: in this case the webmention endpoint can control its user agent, but with this, anything can post to the inbox

tantek: i'm saying by doing that you're making an empirical error you're going beyond the bounds of the problem being solved

bigbluehat: with the annotation protocol we'd like a notification system to publish a notation in the browser and notify arbitrary servers

tantek: the problem being describde was one server hammering another server

rhiaro: the sender could be another server

csarven: we added text to rely on existing cache headers

<bigbluehat> here's a rawgit URL for the patch being discussed https://rawgit.com/csarven/ldn/da56c9afeecbd5d34b9b20ff663981aa4017fb74/index.html#retrying-discovery

aaronpk: yes this is the same conclusion webmention came to, which is URL-based throttling makes sense to respect cache headers, but that doesn't solve host-based throttling

sandro: we're all agreed about respecting cache headers, but we still haven't solved host-level throttling

csarven: how do we actually address the problem of getting senders to not hammer a host in the first place
... what the receiver should do whether the sender is following that or not is a different issue
... adding a requirement that helps the receiver solve its problem in our case is not a requirement we want to introduce

tantek: this entire scenario is about naive receivers
... so any requirements we put in the spec does not solve this problem

sandro: if you are being hammered ,you look at the user agent to discover why you're being hammered, so then you want to find out what you can do to stop being hammered

tantek: i made a request of webmention. to add an informative paragraph that says if you are receiving webmention requests and you don't want to handle them, then blank

sandro: it seems like whatever the solution there we can do with LDN too
... let's say i'm yahoo, and i'm getting all these LDN discovery requests and for some reason it's annoying me

<tantek> where "blank" is left up to webmention editorial description

aaronpk: but how does the receiver know it's an LDN discovery request, that's what the user agent is for, and i haven't heard LDN say they want to recommend using the user agent

<bigbluehat> here's the WebMention issue comment from yesterday's meeting: https://github.com/w3c/webmention/issues/48#issuecomment-248865148

rhiaro: maybe the JS user agents will not be causing problems at this scale because of their nature so them being unable to set their user agent is okay

sandro: once the user agent tells you the request is an LDN request, then what do I do to stop that

rhiaro: an OPTIONS request with a retry-after

sandro: so are clients required to do an OPTIONS request then?

<ben_thatmustbeme> csarven, rhiaro, just noticed there is a broken link to pubsHubhubbub in ldn ED

sandro: we can make this a little fuzzy. we can say if you're being hammered, set this OPTIONS header. and then if you think you're hammering someone, say you should respect the OPTIONS header

csarven: what are the other specs doing in similar situations? not necessarily within this WG

rhiaro: does annotations do discovery?

bigbluehat: yes, via link headers

csarven: given the web architecture, is there a particular reason to mention this in the spec?

tantek: no, this was an empirically discovered problem

sandro: we could publish a WG note that talks about this problem in general and both LDN and webmention could link to it, which is about possible failure modes in discovery

bigbluehat: I would think this exists, because the RDF world scrapes things all the time so someone has to have dealt with this at scale before

tantek: I appreciate your optimism, do you want to find that?

csarven: i don't know if SWP would be the best place to mention this

sandro: i would think a specific note about backing off in discovery

<bigbluehat> Web Annotation Protocol's method of discovery uses Link headers/tags https://www.w3.org/TR/annotation-protocol/#discovery-of-annotation-containers

<Loqi> [Robert Sanderson] Web Annotation Protocol

tantek: sarven made a proposal, which is that SWP add a section about this

rhiaro: i wouldn't be opposed to putting it in SWP, and fine with separating it out if it's worth it

PROPOSED: add a section to SWP describing the likely potential for server-to-server heavy load from discovery requests and approaches to mitigating

csarven: it's not necessarily server-to-server

<sandro> +1 although I think we'll want to move it to a separate document

tantek: the high risk situation right now is server-to-server, so i don't want to water it down with theoretical other situations

cwebber2: i've been trying to figure out if there's any context in which this applies to activitypub. but activitypub is much more specific about recipients. but bigbluehat hit on a good example of where this has heppened, which is a client to server scenario where someone is trying to extract their whole history

bigbluehat: the reason i believe this document already exists is before this there was atom and RSS which use the same discovery mechanism so they were doing the same thing about discovering feeds

tantek: i agree, but there should have been evidence of this happening before

bigbluehat: david, as standin for all of RDF at the moment...
... the case we're dealing with is doing discovery...
... are there known ways to encourage a backoff strategy from the client

david: sure, but that's not an RDF issue, that's an HTTP issue
... sure there are HTTP status codes, like "slow down your requests"

<sandro> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After

<rhiaro> https://http.cat/429

bigbluehat: i'm trying to suss out if whether this is as ancient as i think it is
... .and what others have done in this situation
... i don't think it's unique here and i'm looking for prior art here

david: i'm struggling to figure out why a 503 return code isn't appropriate

tantek: because the server is not too busy...
... it's closer to a 429 "too many requests"

<bigbluehat> https://http.cat/429

david: fair enough

sandro: "for use in rate limiting schemes"

tantek: can we capture this as an action instead of continuing to discuss it here?

bigbluehat: my concern is we were talking about doing things like sending a user agent, rather than using 429 or referencing prior art

<bigbluehat> also https://http.cat/503

Arnaud: do we even need to say anything about this? HTTP is there, you can use those codes, we can just say this is not really our problem. it's a quality of the implementation problem

<sandro> stack overflow about Retry-After http://stackoverflow.com/questions/3764075/retry-after-http-response-header-does-it-affect-anything/23863426#23863426

david: the old guys in the room would say you're right. the problem is the young guys are saying we need to give them context.
... they need some indications fro mthe spec that point out the potential warnings

tantek: so the proposal is to start with a note or section in the SWP document and that it may be worth spinning out into a new note

bigbluehat: i'm happy to help with that

david: the bigger issue in the RDF world is the ease at which it is to write a SPARQL query that will hammer the server. but in the world of query languages there isn't a way to solve that.

bigbluehat: is there a client need to point out always be carefule

david: maybe there is. an in-javascript implementation, the idea is you'd do federated queries but all the joins are done in browser, so all the subqueries going off are much less likely to be complex.

tantek: okay we have a proposal on the table, i'm not hearing any objections

bigbluehat: this was about should we point out to clients while they're being built that they should be careful

<cwebber2> I'll note that this is why when we get people telling MediaGoblin that we should abandon http and use $SOME_P2P_SYSTEM, while they're entirely wrong, they're also kind of right :)

sandro: the idea is we put this in SWP and have all the specs reference it

tantek: it sounds like you'd be okay contributing to that

bigbluehat: sure

<rhiaro> +1

<sandro> (all the specs that give client guidance)

tantek: if you agree with the proposal please +1

<bigbluehat> +1

<AnnBass> +1

<csarven> +1

<cwebber2> +1

<sandro> +1 although I think we'll want to move it to a separate document

+1

<rhiaro> https://github.com/w3c-social/social-web-protocols/issues/38 issue in SWP

<david_wood> +1

tantek: let's declare that resolved

RESOLUTION: add a section to SWP describing the likely potential for server-to-server heavy load from discovery requests and approaches to mitigating

rhiaro: so we will remove the link in LDN until the SWP note exists?

tantek: what do you want to do about LDN

csarven: if the other document is more specific then it's preferrable to point to that. since the cache header bit is non normative

sandro: i'd say take this out and add a specific link to that section that says "if you're writing a client be aware of discovery issues"

csarven: and we remove the specific considerations

sandro: right cause that's going into SWP

rhiaro: next issue. namespaces #13
... we can definitely say this has been widely reviewed as a specific issue

sandro: can we say from this WG's perspective it's a trivial issue, we know LDN needs to use a namespace but that this group doesn't really care

cwebber2: side note, if we find out activitystreams is willing to add a property then you could just use that
... we were planning on sharing their terms

csarven: why LDN decided to use LDP inbox is we figured any out of the box LDP server should be compliant with LDN as a receiver.
... the only thing we needed to add was something like an "inbox" property, let's just reuse an existing namespace
... we have the opportunity to create our own namespace for the spec but for the LD community it doesn't make a lot of sense to introduce a new namespace for a single property

tantek: what do you think of chris' counterproposal

rhiaro: that's second best

tantek: okay is that a CR blocker?

rhiaro: it depends on how we describe it

sandro: tantek you suggested that couldn't be marked at risk

tantek: right beacuse it's a breaking change

csarven: it's true it will break, but the cost of the change is minimal

tantek: so it's potentially doable during CR?

rhiaro: yes i think if we contacted every implementer during CR they would all be able to change it

<sandro> rhiaro: It's just the link in discovery, so it's really easy to change

csarven: so the decision is still pending outside the group

tantek: so let's pick a date by which you will decide that you want to go to CR regardless
... the specific approach is up to you to decide

csarven: that's fine

rhiaro: it's LDP first, whatever activitypub does second
... or we can open a new namespace

cwebber2: for option 3 we might as well both coordinate

<sandro> cwebber2: Preference 1 == use LDP ns, Preference 2 == use whatever AP uses

csarven: LDN is in a way agnostic about the type of things that can have an inbox

<sandro> rhiaro: We don;t want to use a W3C namespace if that's also going to be frozen forever

csarven: sidenote about moving it down to AS... what i would worry is the type of things that vocabulary may have to indicate for things to have an inbox
... for example the domain of some of these is an as object. we don't want that for LDN

rhiaro: we just need to ensure when we put it into AS that nobody puts it in a domain that we don't agree with

<sandro> rhiaro: IF this ends up in AS2, we'll be sure not to include an overly-restricting domain or range

tantek: just to be clear you have two weeks to figure this out, we don't need to solve it in this meeting
... my request is the three of you have a decision by the 11th

rhiaro: are we going to change how we discuss the namespace in the spec right now?

csarven: there's already a note in the spec abotu this issue

tantek: as an aside, i'm going to ask that chris open similar i18n/security/accessibilty issues on activitypub

rhiaro: question. when we were going through our privacy/security section, we had some subsections marked as non normative. how do you decide if something is normative or not.
... we would like feedback on whether this is right

sandro: the one simple thing is if there are any 2119 things then it's a normative section.

tantek: it doesn't make sense to use normative langauge in a non normative section

rhiaro: some of this stuff feels normative but is optional and we don't know how to test it

tantek: normative optional things are fine
... specific example, why is paging non normative

rhiaro: we took this out of the main spec and moved it to a non normative section. it was normative because i wanted to point to consumers to be aware of paging.
... dmitri said we don't hve scope to deal with this

sandro: i look at this and i don't know what to do with it

csarven: we have this subscription mechanism thing. we didn't want to favor one.

tantek: you don't want to *require* one

sandro: i would lean towards just removing that

csarven: i don't want to have that text in there if it's confusing

rhiaro: i wanted to point out to someone saying "why are there only 10 things in this inbox but they're always changing" that it's paging

tantek: another way to address this is to make an explicit note

sandro: you can say there was paging in earlier drafts of LDP

tantek: you can say "this specification does not define a paging model. there are the following notes that you may want to read ..."

<sandro> https://www.w3.org/TR/ldp-paging/

<Loqi> [Steve Speicher] Linked Data Platform Paging 1.0

aaronpk: better to include the note at the specific point in the spec where the reader will be confused about it. like you said, they will be confused when they make a GET request and only see 10 items, so add the note there

rhiaro: can we look at the rest of this section?

tantek: you could move the rest of the "content" considerations inline
... it's unusual to have subsections that flip between normative and non normative
... in general, entire security and privacy sections are non normative. "fyi"

rhiaro: we don't specify a way to do verification, but say you SHOULD do verification but don't specify how

tantek: that's similar to the vouch extension to webmention

sandro: you could rewrite 5.4 to say "ways of verifying" instead of "SHOULD"

rhiaro: i feel like making verification required is good

sandro: that's not security considerations, that's basic protocol

tantek: it sounds like there are pieces in here that should be moved inline
... what sandro is getting at is if there is normative text in the "consideration" section then you should move those into the spec

csarven: what i'm worried about is are we supposed to have a test for that

rhiaro: we say you "should" do verification but don't specify how, so how do we test that

tantek: the HTML spec required image formats, but didn't specify which formats

rhiaro: how about we make a text box and say "paste some JSON here that you will reject and we will send it to you and test that you reject it"

tantek: yeah that's fine

csarven: there's some repetition in the spec about things like discovery in the sender and receiver. if you're only reading the sender section then it makes sense. but we don't want to repeat that again, so part of having that consideration section is so we can refer to it from both

tantek: so you can still put that in a separate section, but call it something other than "consideration" so it sounds normative
... did you consider filling out the security and privacy questionnaire

rhiaro: yeah there's an issue for it
... does a11y have a similar checklist?

tantek: they don't yet, all they have is the horizontal review processes. my experience is they want issues to be fixed inline rather than a considerations section

rhiaro: do they have a checklist we should go through before asking them for feedback?

tantek: no
... what is your approach to get wide review?

csarven: we have a list of people to contact

rhiaro: we have a cursory list of implementations that exist

csarven: we think these are fairly close to passing but are obviously not tested

tantek: yeah that's similar to where micropub got to
... are there any at risk features in LDN?

rhiaro: the activitystreams equivalency media type thing
... about interop between LDN and naive json implementations

sandro: basically if you're thikning in activitystreams and you're trying to post somewhere

rhiaro: according to AS, if you make a GET request wtih an activitystreams accept header, and get back LD json, instead of rejecting it you can ____ to make them accept it

sandro: that sounds like it should be a SHOULD

rhiaro: we originally had that, but some people were not happy because it's not a real media type

sandro: the problem is this SHOULD does not apply to social web people, it applies to LD people

rhiaro: you can say i don't care about activitystreams and i'm going to reject them...

tantek: here's what you can do, if you want to interoperate with LDN then you MUST...

rhiaro: LDN shoudln't really be caring about this specific vocabulary. SWP does care about it.

tantek: it's an easy detail to miss since it's out of band

sandro: LDN is trying to be a cleanly orthogonal technology not actually tied to activitystreams
... can you tell the story of when this would matter
... as a developer i'm trying to do something, how is this text going to affect me

rhiaro: if i'm an activitypub developer, like a client written in C that doesn't have a JSONLD library, so it uses plain JSON.

cwebber2: this happens in a lot of applications
... existing pump.io implementations, many people are not tuned into the JSONLD world
... so they are going to send JSON and not pay attention to the JSONLD

rhiaro: i'm chris' friend and i have my own stupid php implementation of an inbox. chris' server wants to send me a notification. it can discover my inbox just fine, and send a post just fine, even though i don't care about activitypub and his doesn't care about LDN.
... this is like a bridge between worlds where people don't care about each others' specs

<csarven> "my own stupid php implementation" -- got URL?

tantek: we had a request to do this in webmention
... i think it's reasonable to add a non normative activitystreams considerations section in the appendix

rhiaro: so that someone can come to LDN and search for "activitystreams" in the document
... right now this is jammed normatively in the spec which is i think the problem

<sandro> tantek: So make this an "Activity Streams Interoperability Appendix"

csarven: alternatives. i would prefer not to have it at all
... for the greater good i can see how it helps bridge tooling

<sandro> (or sections: LDP Compatibility; and Activity Streams Compatibility

csarven: but it seems to single out one particular way of doing things with LDN, and LDN's position has always been generic
... the spec isn't going to talk about any particular spec

tantek: in my experience the more of those you add in an appendix the more people are interested

sandro: i would expect to see a "Activity Streams Compatibility" section

csarven: but we don't single out any particular vocabulary to keep it open

cwebber2: one argument for it is we've explicitly called out the two specs

rhiaro: this increases the chances of an activitystreams person finding LDN

csarven: i'm okay with an appendix, just trying to get this across

<tantek> this is the example from webmention that is worth considering a parallel of in LDN: https://www.w3.org/TR/webmention/#uris-for-form-encoded-properties

<Loqi> [Aaron Parecki] Webmention

tantek: the section in webmention i think the editor was not happy about adding and adding this one section was the compromise

Arnaud: i think just because you can't list all the options isn't a good reason to not list any

tantek: i'd like to leave this to the editors' discretion to talk about it

rhiaro: we have our exit criteria
... as for wide review, we emailed many lists and people
... some have replied in private
... a research group in germany who did a full presentation with slides on LDN

csarven: their presentation compared semantic pingback with LDN

tantek: are the LDP people in the groups you've reached out to?

csarven: yes, in Web Annotations WG group

tantek: bigbluehat can you speak to if the annotations group can review this?

bigbluehat: now that our charter is renewed it's likely we'll be able to revisit this.

tantek: can we expect an email from the group in response to the request?

bigbluehat: sure. some of us have already reviewed it.

sandro: specifically we want to say that the annotations WG has reviewed the spec and have addressed their concerns

tantek: are there any other WGs you want to absolutely get a response from?

rhiaro: is it worth hassling the data shapes group?

sandro: maybe you could review the specific section that mentions data shapes and say it's mentioning it in an appropriate way

Arnaud: yes the statement is correct. you want me to specifically ask the WG?

tantek: there is a greater burden of proof on this spec because it's progressed so rapidly

rhiaro: we have a couple of w3c member reps not in the WG who plan to do implementations

tantek: okay you have the one outstanding thing to do before the 11th, and are about to send the call for horizontal review

rhiaro: can we do the rehash of this section before we publish?
... can we make a decision now to publish pending fixing all this stuff?

csarven: they were non normative changes anyway

PROPOSED: publish new WD of LDN including fixes resolved by the WG today

<sandro> +1

+1

<rhiaro> +1

<csarven> +1

<cwebber2> +1

RESOLUTION: publish new WD of LDN including fixes resolved by the WG today

<AnnBass> +1

tantek: i was going to ask to have 10 minutes for post type discovery

<bigbluehat> +1

Post Type Discovery

tantek: i've made 1 normative change in response to an issue, commenter has said "sounds fine".
... i did process al lthe issues and mark them up with editorial, or waiting for commenter
... i want more time to work on those, but i believe this one change is worth publishing a new WD

rhiaro: dret said "what is a valid value" and tantek listed 4 values, but my question is what if there are other valid values in the future?

tantek: then the spec needs to be updated in the future
... so it's confidence in the limited set we have

rhiaro: also those are english language valid values so there is an i18n issue

tantek: they are enumerated values

rhiaro: so any language has to use those as values?

tantek: correct

david: in relation to amy's concern, until we get some way of updating stuff like this routinely, the conclusion we came to was for WGs to make it clear what their intentions are
... so it woudl be great if this document said "here is a mechanism for dealing with updates in the future". it's a legitimate problem that we don't know what we're doing

tantek: okay i added a comment to the issue
... i feel like the spec is pretty stable, i'm going to update it over time with what implementations do
... there was a comment amy made in a blog post. that amy implemented something similar based on the UI fields

rhiaro: i made something similar but has different priorities

tantek: can i ask you to file an issue and mention the priority order you came to?

rhiaro: yes but i don't want to commit to an order myself

tantek: sure but i'd like to capture the data point of what you implemented as implementation feedback

sandro: i don't understand.

rhiaro: it means i don't agree with tantek's order of what properties mean what post

tantek: i accept your implementation came to a different conclusion, and want to capture that in an issue

rhiaro: i feel like there is no right way to do this and that's why i feel weird about it being a spec

tantek: the spec is largely a documentation of what various implementations were converging on

sandro: there's no way for me publishing content whether someone's going to use this algorithm or not, right?

tantek: right. as a publisher, you by publisihng the semantics you think are right, that the right thing happens

rhiaro: i see this as a fallback for people who don't have specific opinions

tantek: as a content provider, you care about what implementations will do. this spec is doing your homework for you so you know what the majority of implementations are doing

sandro: so if i post something with a like-of and video, then it's a "like". but if i hear that amy is doing something different, now I don't know what to publish

tantek: this is like browsers and search engines, you don't know how the consumer is using it

Arnaud: i want to ask amy, you don't want to do it this way?

rhiaro: my implementation predates the spec, and then this was written up and it's not how I want to do it.

tantek: this is the gathering of commonalities, so that's why i'm asking you to describe what you do

bigbluehat: what track is this on? cause there are no SHOULDs/MUSTs/MAYs at all
... eventually it has to have a MUST in it otherwise it's a note

Arnaud: i think what benjamin is asking is what does it mean to be conformant

tantek: there's a conformance classes issue that has been filed

sandro: you can have a spec like a vocabulary spec that doesn't have any MUSTs that is still normative

Arnaud: amy, would you be willing to change your implementation to follow this algorithm?

rhiaro: there are some things that are weird, like the reply, since a reply could also be a photo
... i sort my post types by intention rather than by content
... a "photo" post doesn't make sense to me

cwebber2: AS2 dropped having a specific reply post type in favor of having a reply-to property

bigbluehat: are these post types defined in microformats spec?

rhiaro: no, microformats is the implicit

bigbluehat: what is the end result of this parsing algorithm?

tantek: it gives you a singular type

bigbluehat: as...?

cwebber2: when this originally came up, my original reason was being all for it was i was excited to have a route for mapping non-typed microformats to activitystreams
... so it would be useful if it specifically called out which activitystreams types it mapped to
... for example "Then it is an RSVP post" and then also which particular AS2 object

tantek: i think there was an outstanding issue for this
... the plan is to resolve it in the way you described

Arnaud: amy is your desire that the spec change to how you do it?

rhiaro: no, i think it's fine that there are different ways to do it

bigbluehat: i was expecting this was note track. "this is a way to do it" rather than MUST/SHOULD and some other people do it differently

Arnaud: this is describing how *some* implementations do it

rhiaro: this would feel sounder if the implementations referenced had been developed in isolation instead of within one community

Arnaud: amy is saying she doesn't even care to have a recommended way to do this

csarven: it seems like you're using AS2 as an example. how would I know that when I read "rsvp" in a post that is' the same concept of an RSVP in the vocabulary i'm using

tantek: it references the microformats meaning of rsvp
... but i would like input if there is some other meaning of rsvp
... to counter your point amy, a community has found value in converging, so i'm trying to reflect that

<sandro> sandro: How about specifically flagging that a post uses this particular algorithm? eg type=auto-algo-1

tantek: in practice, almost every webmention receiver has implemented at least part of this algorithm based on which type of responses they display on their site

<cwebber2> 🍕🍇🍗🍔🍓🌽😠

tantek: for example when a receiver gets a post with a "like-of" property

annb: what i'm hearing is that tantek says a community has agreed to this, and amy is saying there is a much bigger world, so there are likely other possibilities

tantek: and my request was to give me that input

bigbluehat: if this algorithm is run, what is the expected output

tantek: a post type

bigbluehat: a post type in a specific format?
... in the case of this algorithm i would output an annotation which supports most of these types
... as the reader i wasn't sure what i would take away if i implemented this protocol
... what is the meaning of "a photo post"
... is it an activitystreams thing? a json object? something in my UI?

tantek: there's issue 9, use AS2 language for post types.

bigbluehat: is that what you want the spec to be about? this is the spec for microformats2 to activitystreams2
... would i come here as an activitystreams developer? what about any other devleoper?

tantek: yes, if your system has a strict notion of what type this post is, then you can use this to say what is the one post

bigbluehat: so where are these types defined?

tantek: in this spec

Arnaud: we're missing "what is an RSVP post"

cwebber2: you're saying these are more abstract types, you will call out how these will map to activitystreams but also how these map to other abstract types

<tantek> https://github.com/tantek/post-type-discovery/issues/15 filed for Chris's point

bigbluehat: what i'm concerned about is that this spec is creating a new vocabulary
... so why is there a need for an intermediate vocabulary that is more vague
... is it okay for the WG to spend its time on another vocabulary right now
... if there is a reason for this, it sounds like it's microformats mapping to AS2

cwebber2: [to tantek] how open to this idea are you?

tantek: my first cut will be to document that mapping. if it turns out that's enough then there's no need to add more vocabulary

aaronpk: my concern is that then my implementation wouldn't be using this spec since i don't use the activitystreams vocabulary

bigbluehat: this seems better as something living on a wiki where it's a continuous documentation of what people are doing, rather than a technical recommendation

<rhiaro> +1 bigbluehat

tantek: i think i understand what you're saying by not introducing a vocabulary and not wanting to make it a rec. i would say first use AS2, if your needs go beyond that then document that somewhere else. the only remaining piece that is left is the algorithm that is doing the mapping

bigbluehat: right now it feels like colloquial oral history that needs to be documented, you'll find what overlaps and then you can spec that in the middle. but i don't feel like a w3c technical recommendation is appropriate, it has too much weight. if it's taking this set of conversations, and here's the bit of the venn diagram and how it maps into a particular w3c vocabulary then that's valuable.
... if you zero'd in with that as the use case for the document then you have a specific recommendation that we can ship in 3 months

tantek: i think i would agree with that assessment
... with one caveat, is that there are activities beyond what's in AS2 and i would want to add those

bigbluehat: what you do if that happens is say we don't know the future and have an extensibility section

tantek: i've made some editorial changes and addressed an issue, i would like to request publishing a new WD

<tantek> updated WD staged: https://tantek.github.io/post-type-discovery/index-wd.html

<Loqi> [Tantek Çelik] Post Type Discovery

PROPOSED: publish new WD of post type discovery

Arnaud: one possibiltity is to highlight this outstanding issue in the WD

<rhiaro> +1 with arnaud's suggestion of highlighting issues or calling out general todos

<sandro> +1 given of course there are some important open issues to still resolve

+1

<tantek> rhiaro is there a specific issue you'd like me to incorporate inline before publishing?

<cwebber2> +1 on the basis that the plan is to move towards adding AS2 types

<sandro> annb: +1

<tantek> rhiaro: this one? https://github.com/tantek/post-type-discovery/issues/9

cwebber2: the main question here is how likely is it that this is going to be microformats to as2 types.

tantek: i would expect that

<sandro> tantek: to me yes, it's crucial, this is MF2 to AS2 types

rhiaro: my main concern is if this ends up as microformats2-to-vague
... specific-to-specific is okay

csarven: normally it's better practice that the thing you have maps to something rather than the other rway around

Arnaud: could add that note in the introduction where it says "type of post"
... it seems like people agree, so let's amend the proposal

RESOLUTION: publish new WD of post type discovery, with the highlight of the issue regarding the type in the introduction

<cwebber2> group photo time? ;)

<cwebber2> did I ever present+?

<cwebber2> just in case :)

<cwebber2> ok, we're going to take a group photo with the remote participants on the laptop :)

<cwebber2> though a few people are still trickling back

<rhiaro> scribenick: rhiaro

<cwebber2> beep

<sandro> here

AS2

tantek: Where are we with open issues?

eprodrom: our open issues are primarily editorial
... We've had a number opened since the CR announcement, but typically editorial

<sandro> https://github.com/w3c/activitystreams/issues

eprodrom: So these are ones we're going to be able to knock down prett quickly
... THere are a couple we may have to dig into further
... Primiarly they're editorial

tantek: any normative issues the group can help you resolve?

eprodrom: The only one I see that *beep*

<sandro> (we're having audio problems due to network problems :-( )

<sandro> Aaron's switching to his phone network instead. Hold on.

<eprodrom> Julien can you mute?

<eprodrom> I can't hear you any more

<eprodrom> I'm going to try reconnecting at this point

<sandro> we're trying to get the network working

<sandro> we think it's at our end, but sure, try reconnecting.

<csarven> tantek: eprodrom , could you paste issue URLs to chat

<eprodrom> https://github.com/w3c/activitystreams/issues/370

<eprodrom> This is from Sandro, posted just a few hours ago

<sandro> this group has discussed in thoroughly - I was documenting the outcome of that.

<eprodrom> OK!

<eprodrom> That's what I assumed

<aaronpk> eprodrom, did you get dropped from the call?

<eprodrom> I did, I'll reconnect

<eprodrom> OK I'm back

<eprodrom> Sorry your audio is going in and out

<julien> hey hello!

<tantek> hello julien!

<tantek> scribenick: rhiaro

eprodrom: issue 370 is brand new, do we have a resolution?

sandro: We discussed at the f2f, I thought jasnell might have an opinion
... Maybe we can talk about it more
... My writeup was opinionated compared to what we said around the table
... Where should as2 extensions go? What namespace should they use? Case in point being AP
... In particular should eeach extension go in its own
... In which case the AS2 ns is frozen forever
... The other end is that the AS2 ns somewhere we can keep adding as new things come along that seem reasonable
... Where we set the bar I"m not sure
... This WG can make decisions from the beginning, and as we wind down we spin up a CG
... I propose the bar at, like ietf fo rmost new things, somebody proposes it and if there's no good reason not to lget it go forward after a few weeks of discussion it is improved
... There's a danger of you end up with a bunch of things that aren't used, but that's less dangerous than setting the bar too high
... Being more welcoming toe xtensions is the right attitude to take

tantek: general feeling?

eprodrom: My main concern with adding things to the AS2 namespace, one objection is ??? always be additions of features
... If we are modifying object or person or something it would really require doing a new namespace

<sandro> Clarification --- this is append-only

sandro: absolutely, it would be append only

<sandro> and additions would be clearly indicated as to maturity

eprodrom: If we can manage that then we could have a reasonable expectation of backwards compatbility as the extensions occur
... If' I'm usin gAS2 ns today I'm expecting it to have a certain number of properties, adding a new class would not affect me
... The other one would be ???

<tantek> the other one would be ...

<sandro> +1 we wont break anything marked as stable

<sandro> (ie things in the CR)

eprodrom: think of any case today would expect particular class or property not to exist
... that sounds kind of funny but if I was going to assume that surnames do not exist but then it does, what would that mean
... We don't really have any cases where that happens so I don't think it's an issue

sandro: I think the way extesniblity is defined in the spec right now that won't be a problem

<cwebber2> \o/

eprodrom: I support this

<cwebber2> namespace party!

<sandro> PROPOSAL: Accept Proposal-2 from https://github.com/w3c/activitystreams/issues/370, being clear we're committed to keeping stable things stable

<sandro> details like "14 days" subject to being revised by the group, with a public comment period

+1

<cwebber2> +1

<sandro> +1

<csarven> +1

<eprodrom> +1

<bigbluehat> +1

<aaronpk> +1

tantek: that looks like consensus

RESOLUTION: Accept Proposal-2 from https://github.com/w3c/activitystreams/issues/370, being clear we're committed to keeping stable things stable

cwebber2: doesn't have to be right now, but I'd like to discuss closed issue 312

tantek: eprodrom, any other issues you want help resolving?

eprodrom: I think all the normative ones that are up there we're set
... let's discuss 312
... Very few actually none properties of AS2 are required. No MUSTs.

<eprodrom> "name"

eprodrom: The only property we have is name with a SHOULD
... If you run an AS2 document through the validator, it will give you an error for objects which don't have the name
... there was some question about whether we shoul dalways have a name
... Should it be a SHOULD? we've gone through this a couple of times and I think we decided to keep it a SHOULD

cwebber2: I remember not being pleased with it being a SHOULD
... rhiaro and I have been doing implementatons and both ran into issues where we weren't rpoviding names when it didn't make sense
... I'm not sure I agree with the view that if you can't think of a good name provide a stupid name
... That means in my consuming code I can't tell if a name is a good name or not
... Name is used to indicate a subject
... in AP
... If a subject isn't provided you could pull it from the post itself, but taht should be up to the UI
... rhiaro ran into places where names didn't make sense
... And then the things she was producing were not validating

<Zakim> cwebber, you wanted to discuss after 370 resolution to discuss https://github.com/w3c/activitystreams/issues/312

tantek: the validator was enforcing a should which makes sense

cwebber2: the pumpio community does not always use name

tantek: (makes sense in the current spec)

eprodrom: pumpio is as1. There are cases where there's not a name

rhiaro: what chris said
... I have activities without names
... they are redundant in many cases

cwebber2: right, why would a like need a name

eprodrom: from the pov of an implementor that typically having... like needs a name in pumpio you see it in the minor feed
... It's nice to have it

cwebber2: I'm going to argue this is an i18n problem if you end up requiring a name
... You could say 'blah liked it' in the native language
... So if you require that and then you use it because tha'ts provided even if it's stupid it'll be english only

eprodrom: namemap

cwebber2: are you going to end up dumping a huge namemap on every object that's a like?

rhiaro: Client can craft that string from other properties in appropraite language

bigbluehat: so the issue is it's a should?
... It inherits from atom title which was a must
... everybody hates the must in title

<eprodrom> https://github.com/e14n/pump.io/blob/master/lib/model/activity.js#L1113

bigbluehat: so it's moving down the stack
... but I don't know that you should push it all the way toa may

cwebber2: It could be an informative note

tantek: I'm going to flip this and say unless there's a justification for the normative requirement it shouldn't be there

bigbluehat: is the bigger issue it's for all types?

cwebber2: yeah

tantek: what problem is it solving that it is a shoudl?

bigbluehat: the point with atom is you'r egonna list stuff so you need a text string to click on
... atom said if you don' thave the title put the date
... most people put in title
... but it was the thign peopel tripped over with comments
... jasnell had to deal with title there
... if you don't want to put a nmae, don't put a name. It's a SHOULD

sandro: if somebody makes up a bad title it's not ignorable

aaronpk: if he can't always trust the name he will never trust the name

cwebber2: Iwouldn't be able to tell how to trust it
... Other people would implement things based off the validator and I would no longer be able to tell if it's useful
... There are certain types where if somebody supplies a name I would show it, and if someone hasn't, I wouldn't want to put subject: name

csarven: jasnell mentioned a while back that not everything is backwards compatible, so wehther this is one of those things we want to carry forward, bigbluehat said it was must before, whehter that's even a concern at this point

bigbluehat: the ohter option is to make it a may

cwebber2: or just don't say anything

bigbluehat: what will break if there is no name?
... what's another story?

tantek: consumers believe they need something (like a reader), like to click on, that's reasonable
... Due to .. I don't know where this methodology came from - results in a *publishig* requirement
... Which results in the unintended consequence of publishers making up an x when they are required to have an x ,where they otherwise wouldn't
... Then the consumer sees that and thinks this is garbage, I can no longer depend on a thing I wanted to be able to depend on
... The leap is from consumer things they need x to spec says publisher is required to publish x, which is a bad methodology
... no one is disagreeing with the consumer need, the problem is with the logical leap to therefore make that a publisher requirements
... I don't know where that logic became accepted
... empirically it has been proven as a failed design approach

eprodrom: one side then the other side
... We have a comment. It doesn't really have a title, but if we need to refer to it we have to make up some sort of name for it
... we can have every single consumer that sees that comment make up a fake name
... or we can have the publisher make a fake name
... it's making it easier on the consumers to say hey publishers we know it's going to need a fake name so you make it up
... sounds nice, th eonly problem is now we have given a fake name ????
... If we have a publisher assign that fake name 'a comment by chris' we've given it the same kind of meaning as a name that was assigned by a user
... that probably is meaningful in context
... we would expect that consumers should be very respectful of names and titles created by a user, but not need to be as respectful as made up names
... may want to internationalise them

<cwebber2> yes

eprodrom: I see the point that chris has that leaving out a name says that this object doesn't have a meaningful name, and you can use any kind of context clues liek it's type or it's author in order to create a name
... and you can internationalise that, you can call it a tweet instead of a comment, or a status update instead of a note
... so it actually gives consumers, even though they have that burden, it gives them freedom

<rhiaro> +++++++1

<Zakim> cwebber, you wanted to say that "if we're saying it's a SHOULD so it's not required enough, every client has to produce a fallbck anyway"

cwebber2: You started to say the other side of things, which is we want to give them something, so fill in something... and that's why publishers sholud give the name. BUT it was also previously said that this is a should so don't die on that hill
... But it means that every service has to privde a fallback *anyyway* as it was a should
... but that was yes to what you said.

<Zakim> tantek, you wanted to note consumers end up preferring to know when it is a real name vs a made up name

cwebber2: local context, internationalisation

tantek: implementaiton experience with this.. when consuming code designers start out requiring a name, and people or algorithms start making up names. Then consumers would rather know if names came fro the user or were made up
... and the information as to whether it's made up or real turned out to be crucial

<cwebber2> +1, knowing whether it's synthetic or intentional is good

<cwebber2> +1000

tantek: and they went to great contortions to detect if it was made up or not and decide what to display it
... the consumers thought they wanted something, but givne the interactions that occurred they ended up not wanting the name unless it was from the user
... and rather than show a synthesised name they would show nothing and that tells me that it is bad advice to lean on the should

<aaronpk> +1 I have actually written that code

tantek: to lean on pushing people to provide a name

<cwebber2> I really want the info of "nobody has provided a name" :)

tantek: and make it a may and list specific situations where it's a sholud or a must
... I commented on the issue with that

bigbluehat: I think there's agreement that there are places where you MUST provide a name. I think rhiaro just said that. Articles and things
... The question is really the vector of control over the name
... What wholud happen in that case
... IN the case of atom they MUSTed it, SHOULD is not a requirement
... hopefully implementors are sane enough to say this is a shoulld but I'm trafficking in likes so I can leave it out
... if they provide a title your implementation can ignore it or replace it

cwebber2: we have 3 implementations that have run into this

bigbluehat: is the recommendation to reduce name to a may?

cwebber2: I think we can drop it and have a note that encourages supplying a name wher eappropriate

bigbluehat: i want the case aaddressed where there are types which must have a name
... is a Note sufficient for that use case
... Or is there a way to specify name contextually such that it is a MUST on article and not on everything else
... That sounds more like the issue that's being addressed
... not that name is bad, but there are scenarios where giving the publisher the power over the name is that they might give me crap
... the bigger question is over what types should the publisher have authority even if they send you crap
... and at what point does the client need to care whether or not there must or may not be a name, and trust that even if the publisher does soething insane it should still display it
... and which you want to encourage more to do the right thing
... do you encourage the client to ignore name on Like
... my concern is that if you lower it too much and ??

rhiaro: SHOULD means MUST unless really good reason

bigbluehat: web platform tests is not made to test shoulds
... thefore it's ignorable
... you can't fail a test because of a should
... web platform tests says shoulds are irrelevant
... if you only do the musts you ust be able to pass the tests
... so what we've done is hack the wpt code to still test the shoulds and not fail, but provide a note
... and now we're arguing about wpt about whethers houlds should be testable
... which is why I say they have no meaning when it comes to implmenetation and will pass the tests
... and some people will go out of their way to do shoulds, but as far as passing they only have to do the musts

tantek: in practice it hasn't been ignored

bigbluehat: I'm talking about testing to pass rec

csarven: in response to tantek's proposal here and what bigbluehat has been saying about whether some of the properties would fall under musts or shoulds
... in some cases it seems like it makes sense, some cases you can get away without
... what I'd like to know is the cost of those differentiations.. if I have this vocabulary in mind and I"m implementing would I always think name is a global thing I can apply to everything, or is it only applicable to some of those objects
... On one hand name I can put it anywhere if I want
... bigbluehat is cautioning going all the way from must, should or possibly going with may or omitting

<Zakim> cwebber, you wanted to say that I don't want a SHOULD when it's the wrong thing, in the case of a Like, regardless of tests

<tantek> agrees with cwebber

cwebber: I wanted to say that even if it doesn't matter to pass the tests, SHOULD feels highly instructive to an implementor
... that really isn't what I want to tell somebody for every like
... it seems like what we started talking about is that maybe the should is in the wron gplace
... if it's on article I'm fine with it
... that's th eone thing in the spec I can say yeah I expect every article I read to have a title
... I don't expect it of a note, or a tweet, but I expect every aritcle I read in the newspaper to have a title

rhiaro: just to call out that kongaloosh and my own experience feeling obliged to generate a name from the SHOULD

bigbluehat: there is at least one case where there should be a name, which is Article
... I don't want to hurt that

eprodrom: I think I agree with making this a may and should on article
... The only reservation I have is that james has a strong opinion about this
... he's made some pretty stroing points about it before so I"d like to get his opinoin before we change it

<bigbluehat> current spec text on the topic: "While all properties are optional (including the id and type), all Object instances should at least contain a name (or equivalent nameMap)."

<bigbluehat> from https://www.w3.org/TR/activitystreams-core/

<Loqi> [James M Snell] Activity Streams 2.0

<cwebber2> PROPOSED: Remove SHOULD from name/nameMap on general Object and add SHOULD to name/nameMap to Article.

<bigbluehat> specifically https://www.w3.org/TR/activitystreams-core/#asobject

<Loqi> [James M Snell] Activity Streams 2.0

cwebber2: I would be okay with MAY there, I just don't think we need it

tantek: the reason this came up is because you and rhiaro cited new data, implementation experience, which helps us drive changes during CR
... I think that is sufficent to justify a change if we have consensus
... opinions?

sandro: jasnell can formally object when he reads the minutes or proposal

tantek: so, vote

+1

<cwebber2> +1

<aaronpk> +1

<AnnBass> +1

<sandro> +1 seems like the right solution

<tantek> +1

<eprodrom> +0

<bigbluehat> +0 not sure Article is the only case; needs more discussion

cwebber2: this proposal does not block adding it to other things

<csarven> +1 to Article (possibly for the others)

RESOLUTION: Remove SHOULD from name/nameMap on general Object and add SHOULD to name/nameMap to Article.

<sandro> sandro: Our understanding is this does NOT require a new CR, because it doesn't make any implementations need to change

tantek: evan wants to check with james before making the change

<jasnell> -1. special casing it doesn't really buy anything and SHOULD still allows for exceptions where needed

<eprodrom> OK

<sandro> jasnell, want to call in? We're on google hangouts.

<eprodrom> My screen froze; rejoining

bigbluehat: what we're saying about special casing is my +0ing concerns

tantek: this argumenet that SHOULD allows for exceptions is not sufficeient, it's not new
... we need new data

<cwebber2> jasnell: https://hangouts.google.com/call/pza7kb5zqnginhh43223mtdjiae

<cwebber2> could you call in?

sandro: we can't ignore jasnell's -1 without hearing them out

tantek: we're looking for new information

<jasnell> can't at the moment, will just comment here: the whole reason it's a SHOULD is because implementation are not expected to understand all @types

<cwebber2> jasnell, did you read my i18n concerns

<jasnell> if the implementation wants to be able, at a bare minimum to say "Sally uploaded a thing", the name gives a minimal bit of display for the "a thing" part

<rhiaro> I would say that if you're making an extension, and you don't think people will be able to figure out how to label it, *put a name there*

<rhiaro> but not that everyone is required to put *something*

<rhiaro> we're not saying Article is the only thing that can have a name

<jasnell> if we want to say that for any type NOT in the core vocabulary, make it a should, but for everything in the core vocabulary it's a may, then I can live with that

<aaronpk> wait wait this is different

aaronpk: there are two totally different things going on
... 1. Some objects have a user entered name where the user is typing out a thing
... for those cases I absolutely agree a machine should not automatically insert something there and mix machine and human created content
... 2, totally separately, is he wants to be able to generate as entence that says 'sally uploaded a thing'
... that's a name, but it's a name of the type of the object, not a human entered name
... in that case it makes sense to put something there
... the point is it's machine generated
... for those cases it makes sense

<jasnell> it's not always machine generated

bigbluehat: and you ahve a textual fallback

<jasnell> btw, this is why `name` used to be called `displayName`

<jasnell> the `display` part of it was significant

rhiaro: the localisation is at the consumer end not the publisher

<jasnell> in any case, as I said, if you want to say that name is a MAY for the core types and a SHOULD for extension types, that would be fine

bigbluehat: jasnell is pointing out it used to be displayname
... it's intent is the same

<rhiaro> jasnell - fine with that

cwebber2: we discussed that we would use name for the user supplied name

<sandro> jasnell, the problem seems to be that publication software will machine-generate a name which isn't as good as what the consuming-machine would generate (eg in the local language) --- always in the case where the human author didn't provide a name.

bigbluehat: Shane of the testing group who said all the things about must and should, is available to explain w3c process + testing requirements to exit cr, and how heavy handed we should or should not be with should, if we care to hear from him

<jasnell> but it's quite likely that the consuming machine will have no idea what type of object it is

bigbluehat: it will matter shortly we should get that right

<jasnell> at least when we're talking about extension types

tantek: we have evidence showing that it's harmful

<jasnell> which means that the consuming end won't know what name to pick in any language

cwebber2: I want to discuss this, but not right now

<sandro> jasnell, for extension types, get that from the definition of the extension type. It's goofy to say every use of an extension has to give a name to the extension type, which is conflated with the human generated name.

<jasnell> having the publisher give a human readable name in any language at least gives the consuming end something it can translate if it has no idea what this thing is

<cwebber2> 1) I want to be able to know *when a name was not provided in a meaningful way*.

<rhiaro> +1

<jasnell> sandro: how?? there's no programmatic way of getting that information for the extension type

<jasnell> at least none standardized

<eprodrom> "straight"

<sandro> I mean, there is, rdfs:label, right?

<eprodrom> "pubst"

<tantek> eprodrom: ?

cwebber2: and there's the i18n thing
... saying you have a namemap means every publisher has to have its own translations

<eprodrom> tantek: what Pubstrate could call notes

cwebber2: almost every application comes with a UI that should have those applications

<cwebber2> 2) having a 5kb Like with a nameMap is not great and might not even have all the info/languages a client could provide

<Zakim> tantek, you wanted to also note we don't require HTML publishers to provide all languages

cwebber2: since you can infer something there stick it on there.. but I want my application to have better i18n than the publisher to be able to do the right thing

<sandro> +1 cwebber2 the format shouldn't confuse human-generated-data from machine-guessed-data

tantek: trying to cram the fallback behaviour and the syntehseising behaviour and the user chosen title behaviour into one property, take this with whatever salt you want, we've found in indieweb that it gets too overloaded and couldn't come up with a sensible arguement to try to figure out when it is what

<jasnell> fwiw, AS1 also had separated displayName and title... also for this reason

tantek: the alternative approach we have that seems to be working is to prefer name to be a user significant thing, rather than synthesised

<jasnell> displayName holding the simple displayable, and possibly machine generated name, title for holding more complex markup

tantek: and if a publisher wants to provide a text alternative to a type of post that they think consumers might not understand, that the summary field or property is a good place to do that

<jasnell> but the WG saw fit to remove title

tantek: that has been shown to be functional

<sandro> and was displayName entered by user, or hardcoded as the class name, in every human language?

tantek: if something understands likes it displays it as a like, if it doesn't it can look at summary
... the first point: summary as fallback has been useful

<cwebber2> jasnell, right

<cwebber2> jasnell, I think that's what's causing all this trouble

tantek: Second point is that the entire discussion of providing dozens of translations is a bit of a red herring because there's no expectation or requirement of anyone publishing html to provide nuemrous languages
... there's no burden like that

<jasnell> so what I would actually recommend is bringing back title and leaving name alone

<jasnell> use title for the human-provided part

<jasnell> name for the potentially machine-generated part

<jasnell> and leave name as a SHOULD

<aaronpk> jasnell, and also recommend that the *software* generate that name, and NEVER use user-entered content in the name?

<sandro> Makes sense.... requires another CR unless we consider title an extension.

<tantek> jasnell, except "name" is the more meaningful / semantically relevant term (i.e. a person's name). whereas "title" has tended to be more presentational.

<jasnell> I don't think we can say never user user-entered content there

<jasnell> because it simply may not be possible for the application to generate a reasonable name

<Zakim> aaronpk, you wanted to say what jasnell said

aaronpk: if we have different properties for these uses, then the problem goes away

rhiaro: we could use a different property instead of summary because we might just push the same problem onto summary ifwe use that

aaronpk: then if you use property over name the consumer can know that it was probably syntehsised
... So consumers can rely on the two different uses of the name

<cwebber2> rhiaro: so saying name as a 5kb thing is not just a red herring, if you always provide name/nameMap, you expect publishers to always provide translations for the type, but you also won't know when it's user provided, which makes correct translation impossible

aaronpk: this would also have to come with very clear guidence to publishers so they don't confuse the two
... but splitting out these uses of 'name' woulld actually solve the underlying issue

<cwebber2> jasnell, FYI I am +1 on separating name/title again

tantek: I want to separate out the fallback issue

<sandro> the className (aka AS1 name) shouldn't be considered instance data

cwebber2: a revised proposal to see if we split it..

<rhiaro> sandro that's what I was tryign to say

tantek: if we split off the fallback functionality from name we can amend proposal

<cwebber2> jasnell, I will try a revised proposal

<jasnell> cwebber2: +1 thank you

<rhiaro> aaronpk - it does'nt necessarily have to include the class name, but just somethign that makes sense for that extension

<rhiaro> I dont' think we should overprescribe that in general

<jasnell> adding title back and adding some recommendation text around it saying to use title for human-provided title and name for simple label is the way I'd go. For linked data based implementations, as:name can be mapped to rdfs:label if it makes things easier

<tantek> jasnell, I'd reverse that since name is meaningful and title is presentational

<rhiaro> I like name vs fallbackName

<cwebber2> PROPOSED: Return distinction between "user entered or otherwise significant name" and "text fallback" and shift SHOULD from meaningful name to text fallback.

<cwebber2> +1

<sandro> Also, that needs another CR unless we're careful

<tantek> +1

+1

<aaronpk> I am also curious to hear the cases where the fallback name would be user-generated

<aaronpk> +1

<tantek> +1 with use as "summary" for fallback text since that seems to work, and does not require adding a new term (thus does not require a new CR)

<sandro> +1 as long as we do it without a new CR, by keeping "name" the same, and adding an extension for the other function

<eprodrom> Can we come up with a better property name than "fallbackName" ?

<cwebber2> eprodrom, yes this name is not the permanent choice of naming

<jasnell> use label if anything

<jasnell> as:label would have a natural mapping to rdfs:label

<csarven> ^ +1

<sandro> jasnell, the rdfs:label I'm suggesting is from the CLASS not the INSTANCE

<jasnell> {"id": "http://abc%22, "type": "http://abc/thing%22, "name": "My thing", "label": "thing"}

RESOLUTION: Return distinction between "user entered or otherwise significant name" and "text fallback" and shift SHOULD from meaningful name to text fallback.

<sandro> jasnell, that makes sense in that framing. The examples being spoken in the room have been different.

<csarven> ☕

<sandro> NOTE THIS REPLACED ABOVE RESOLUTIONS

<jasnell> {"type": "add", "actor": {"name": "James", "type": "Person"}, {"type": "http:/abc/thing", "name": "My thing", "label": "thing"}} == James added a thing or James added "My Thing"

15 minute break

<aaronpk> jasnell, that makes sense. i could see a consumer that's generating a notification do something like "james posted {if strlen($name) > 100 then "a" $label else "$name"}"

tantek: after this we'll discuss PuSH

<cwebber2> thank you for working through this with us jasnell

<jasnell> label can be define as a simple string, no language map

<jasnell> consuming implementation can use it to select a translation that makes sense

<sandro> ALSO, CONTINGENT ON NOT BEING ANOTHER CR

<sandro> jasnell, we're going to break. Do you want to +1 or -1 that resolution?

<ben_thatmustbeme> by the way, i noticed that monday is cwebber2's birthday (assuming my calendar is telling me the truth) so wish him a happy early birthday

<jasnell> +1

<sandro> ben_thatmustbeme, cwebber2 says thank you!

<sandro> (he was walking away from his computer)

<ben_thatmustbeme> i heard

<sandro> great, jasnell

<sandro> any thoughts on whether we make the other property an extension or waste another 6 weeks and risk everything on another CR? :-)

<sandro> (maybe there's a way to slip it into this one, but I doubt it.)

<jasnell> that I don't know

<jasnell> had we kept title around in the first place this wouldn't have been an issue

<sandro> Yes, if you can dig up who argued for removing it, you can whack them over the head with a big "i told you so"

<aaronpk> likely the reason it was removed was that the actual motivation for having it wasn't written down in the first place

<sandro> (and maybe the rest of us bear responsibility for not thinking it through enough at the time.)

<ben_thatmustbeme> sandro, tantek said we are going to go to pubsubhubbub since julien has been waiting patiently for some time now

<ben_thatmustbeme> and then go back to AS2 after

<sandro> eprodrom, do we still need to talk about AS2 testing? You realize that all has to be done ... soon?

<eprodrom> Yes

<aaronpk> had the spec clearly mentioned the two distinct uses of name, then it may not have been removed in the first place.

<aaronpk> documentation++

<eprodrom> I think the open question is whether we have a full test suite

<Loqi> documentation has 7 karma (1 in this channel)

<sandro> eprodrom, I don't think most of us are in any position to assess that. Do we need help in figuring that out?

<sandro> (I'm going to go walk around for a minute. bbiab.)

<eprodrom> So, here's the thing: our test documents mostly come from the spec itself

<eprodrom> Examples from the document

<eprodrom> They're pretty comprehensive

<sandro> that's promising...

<eprodrom> OK! We can discuss after PuSH maybe?

<jasnell> when y'all are back on AS2 someone please mention me here so I'll get the notification

<jasnell> have fun!

<eprodrom> I'm a likable guy

<aaronpk> jasnell, we're gathering again, four of us here right now

<eprodrom> uh

<eprodrom> what

<julien> Here! sorry

<eprodrom> I am not convinced

<eprodrom> I am off for 15 min, unfortunately

<eprodrom> Going to be back v soon

<scribe> scribenick: rhiaro

Pubsubhubbub

tantek: there's an update to the ED of PuSH, has anyone read it?

aaronpk: AYE
... It appears to be the same thing as the 0.4 spec, i did not see any changes other than syntax, is that correct?

julien: it was mostly cosmetic changes
... I'm still not sure whether this is the right appraoch for ?? ... more clear on how the thing works with different types of content, and I'm not sure how to do that in the spec
... Don't know how to formalise that

aaronpk: tantek, the new ED that julien published is the same in terms of functional content as 0.4
... that's establishing a baseline for starting the new work here
... the changes that have been made are cosmetic around references etc

tantek: upon readaing it did you come upon anything you would consider a fpwd blocker?

aaronpk: what is a blocker?

tantek: that you think it must be fixed before we publish as fpwd?

aaronpk: I did file some PRs for type level fixes

julien: I will merge them today

<cwebber2> eprodrom, could you reopen https://github.com/w3c/activitystreams/issues/312 until resolved?

aaronpk: pretty minor, updated references
... Two content things that I'm going to open issues on. I don't know if they're fpwd blockers, inclined to say no
... But i don't know exactly what the criteria are for that

tantek: you have to feel pretty strongly that it's wrong

aaronpk: one example is that it recommends using sha1 which is deprecated
... that feels wrong
... Simple fix is to switch it with sha256 or sha512
... Not changing how spec works, but fixing broken algorithm

julien: I'm fine with changing it. I think the spec allows, the signature starts with a type of algorithm that is in use
... I think we should make the spec more ?? and specify that the signature is a combination of a key and a value and the key should be the address and the value should be the signature

aaronpk: that's definitely not how the spec is writtne, it looks like it's hard coded to sha1
... that's fine to make it explicit that the first part of that parameter is the algorithm
... I belive jwt has a similar mechanism of sepcifying the hasing algorithm so we could look at tha tfor some text

tantek: that sounds like something we should fix before fpwd
... *summarises*

<sandro> Use https://www.w3.org/TR/WebCryptoAPI/#sha please

tantek: anyone else reviewed?

rhiaro: I reviewed, no opinions
... it seems fine, and people hav eused it in this state

tantek: i have read push0.4 but not this draft, but if this reflects 0.4 I think that would be an excellent fwpd

sandro: diff?

aaronpk: there are no functional changes
... only syntax

julien: i rephrased the abstract

tantek: if no-one else has any objections I would like to propose..

PROPOSAL: Take Pubsubhubbub to FPWD from ED with the fix of the SHA change

<sandro> +1

<cwebber2> +1

<tantek> +1

<rhiaro> +1

<julien> +1

<scribe> scribenick: cwebber2

<aaronpk> +1

<aaronpk> here is the sha1 issue: https://github.com/w3c/pubsubhubbub/issues/4

tantek: I'm seeing all +1s, let's call this resolved
... group has decided to take PuSH to WD, excellent
... julien, with that change, how soon can you make changes / go to FPWD

julien: I think next monday (??)

<csarven> julien: s/thecontent/the content

tantek: see if you can get approved today, let's see if we can get published by monday

RESOLUTION: Take Pubsubhubbub to FPWD from ED with the fix of the SHA change

tantek: great congrats julien, looking forward to publishing this draft and iterating
... any pubsubhubbub issues you'd like to discuss with the group

julien: more of a question of the formality, where can I read more on how the process works

tantek: that's an issue rhiaro raised earlier, step to step is not totally clear, but rhiaro can you guide julien through?

rhiaro: yup
... aaronpk is going to start raising issues, then it'll become more clear

sandro: we'll start getting issues filed, have i18n issues checked, have a tester, then start to get people to report implementations and list those
... that's basically what we have to do

<tantek> julien this may be helpful too: https://www.w3.org/wiki/Socialwg/Github_Process

julien: is there any way to change the name?

tantek: short or whole name

julien: whole name, it's not easy to pronounce esp to non-english people

sandro: great to come up now, because for fpwd we need the name

<sandro> http://www.w3.org/TR/push or .... what?

cwebber2: PUSHHUB

<ben_thatmustbeme> my only concern of changing the name is the recognition of it

<sandro> http://www.w3.org/TR/pubsub

<aaronpk> web push?

aaronpk: *narrowed eyes*

<sandro> http://www.w3.org/TR/webpush

julien: I think maybe web hook?

<rhiaro> websub

<bigbluehat> one caution is audience...not sure everyone would find their way to the new one

julien: is there something called web push already?

<bigbluehat> HTTP Push https://tools.ietf.org/html/draft-ietf-webpush-protocol-09

<bigbluehat> oh

<bigbluehat> webpush

sandro: there's http push

<sandro> http://www.w3.org/TR/pubsub

<bigbluehat> actually

<aaronpk> pupu

julien: what about hookpush

sandro: over time pubsubhubbub has grown on me

<sandro> PuSH

sandro: there's maybe some question of how much to abbreviate

<sandro> http://www.w3.org/TR/PuSH

sandro: like the url, we could use the case sensitive PuSH... probably... don't know if we want to...

<sandro> http://www.w3.org/TR/pubsubhubbub

<ben_thatmustbeme> pubsub i think would be fine

<tantek> https://github.com/w3c/pubsubhubbub/issues/5

tantek: we are not going to bikeshed in real time

sandro: except we need an answer to get to fpwd

er

tantek: that's why I made it FPWD blocker
... how much time do you need julien after we get the name

rhiaro: we can't approve without the name fyi

tantek: if we get a short name that would work

julien: I prefer push

<bigbluehat> I'm +1 for keeping the name--given find-ability

aaronpk: that won't fly because push-api is already a spec

<ben_thatmustbeme> pubsub?

cwebber2: 0 on push

<bigbluehat> pubsub could work

tantek: any alternatives?

julien: I'm ok with pubsub

<ben_thatmustbeme> pubsub +1 here too

<bigbluehat> it's a Thing https://en.wikipedia.org/wiki/Pubsub

<bigbluehat> ...though not a protocol

<sandro> http://www.w3.org/TR/pubsub Web Publish Subscribe (PubSubHubbub)

PROPOSED: Use shortname of pubsub for shortname for now

<sandro> +1

<cwebber2> +1

<bigbluehat> oh...and a Google product https://cloud.google.com/pubsub/

<julien> and XEP60

<aaronpk> +1

<tantek> +1

<rhiaro> +1

<bigbluehat> +0

RESOLUTION: Use shortname of pubsub for shortname for now

<sandro> Note https://www.w3.org/community/pubsub/ was this CG

tantek: feelings about what to do about pubsub community group?

julien: I don't have any

<bigbluehat> Keep the CG around for future extensibility

julien: if nobody participates and nothing happens any more, I think we can close it, but otherwise I think we could keep it

sandro: we don't need to shut it down we just don't have much conversation there

aaronpk: this group is probably going to end in 3 months

tantek: by closing this group it will tie in with figuring out what to do with everything else, which we already need to do
... do you see any reason to create any forum for anything else, julien?

<eprodrom> +1

<eprodrom> MISSION ACCOMPLISHED

PROPOSED: Close pubsubhubbub community group with "mission accomplished", draft incubated, it's now a rec-track working draft as part of socialwg.

<cwebber2> +1

<tantek> +1

<aaronpk> +1

<eprodrom> http://content-img.newsinc.com/jpg/1459/24779720/4518170.jpg?t=1367337600

<eprodrom> +1

RESOLUTION: Close pubsubhubbub community group with "mission accomplished", draft incubated, it's now a rec-track working draft as part of socialwg.

<eprodrom> publish subscribe pandemonium

<eprodrom> Here

tantek: eprodrom's kind of a big deal

<eprodrom> ha ha

tantek: it's always good to compliment someone before you hand them a heap of work
... we are going back to as2 next steps, thank you julien... I hope you can join us on tuesday, sounds like we have critical mass of things to discuss

<eprodrom> :thumbsup:

tantek: I recall eprodrom saying he thought we were done with normative issues, then cwebber2 brought up a "little issue"

<eprodrom> Yes, I think so

tantek: I'd like to see if anyone has anything else to discuss, and then leave it to editors
... not hearing specific as2 issues being raised, let's talk about general CR to PR status
... how are we moving with test suite status, eprodrom ? do we have a complete test suite?

<eprodrom> I am unmuted

<eprodrom> I'm going to try to reconnect, sorry

<aaronpk> hangouts does that

<aaronpk> especially in chrome 😂

<cwebber2>

<eprodrom> That is awesome

<Loqi> [@bigbluehat] Yeah #TPAC2016 Pretty sure @SocialWebWG is done with my help... ;) (http://twtr.io/1HL17LToUWw)

<Loqi> [@dustyweb] .@SocialWebWG is taking federated names and getting things done (http://twtr.io/1HL18Cd0Y_8)

eprodrom: there are two parts of the test suite

<eprodrom> Can you hear me?

<eprodrom> Weird

<AnnBass> no ... exceedingly painful static

<eprodrom> At this point I think I need to type

<eprodrom> I just muted

<eprodrom> So let me write it out here

<eprodrom> Question of test coverage

<AnnBass> hmm hard to be heard when muted

<eprodrom> Two parts of the test suite

<eprodrom> AnnBass: I think I'm going to just type it out

<eprodrom> First is the validator

<eprodrom> Second is the test documents

<eprodrom> Test documents PRIMARILY come as examples from the spec itself

<Loqi> [@csarven] .@SocialWebWG at #TPAC2016 passes all tests. (http://twtr.io/1HL1NQVbyso)

<eprodrom> And there are plentiful examples

<eprodrom> So the big question with test coverage is if we have features described in the doc that aren't in examples

<eprodrom> I've been going through the docs and haven't been coming up with anything

<eprodrom> At this point I could probably use a set of fresh eyes

<eprodrom> Who could help out with this

<cwebber2> eprodrom, I *might* be able to

<cwebber2> eprodrom, I feel like I would be a good candidate but am a bit overloaded

<eprodrom> That's not a bad way to do it

<sandro> sandro: you could ask implementors who report results to try to help a bit, contributing tests

<eprodrom> Let's just say that we haven't had anyone who's running the tests say, "I had a feature I wanted to test but there wasn't a test document for it."

<eprodrom> But yes I can do that

<eprodrom> For publishers we have the validator

tantek: we have the general validation tool, but do we have anything that says "generate an activity that provides X"

sandro: one funny trick would be to check the validator if every feature had been tested by somebody

bigbluehat: if we had some privacy policy

sandro: yes, it should prompt to ask if you are ok to record
... I'm sure eprodrom has thought about this

<eprodrom> I haven't!

<eprodrom> We don't record the data in the validator but we could

sandro: are we getting reports of people producing as2, or only consuming as2?

<eprodrom> We are asking for reports for both

<tantek> https://github.com/w3c/activitystreams/blob/master/implementation-reports/template.md

tantek: at this point I think we need implementations to run tests for their conformance class and file implementation reports

<tantek> https://github.com/w3c/activitystreams/tree/master/implementation-reports

<eprodrom> None yet

tantek: do you have any insight eprodrom for implementations to file reports?

<eprodrom> We have one submitted by Apache Streams

<eprodrom> cwebber2, SUBMIT IMPLEMENTATION REPORTS

<eprodrom> Very important

rhiaro: if we're looking for potential implemmentations, activitypub compatible implementations are at minimum consumers

cwebber2: if not producers

tantek: when can you file implementation reports cwebber2

cwebber2: the week after I hit CR

sandro: though filing implementation reports might help with AP process

csarven: I may be able to provide an implementation report, I am doing just vocab, but it's publishing and consuming

tantek: any rough estimate on when you can publish an implementation report

sandro: 2-3 weeks?

csarven: yep

sandro: and we should talk about PR!

tantek: there are rumors on the internets that annotations uses as2

bigbluehat: that's true

tantek: could you submit reports?

bigbluehat: well we're only depending on as2 collection terms / pagination model

<aaronpk> julien, I have an idea for new text for the sha1 section, would you like me to PR that too?

sandro: in theory that should still pass the validator

bigbluehat: it's going to have to do more than pass the validator

<bigbluehat> https://www.w3.org/TR/annotation-vocab/

<Loqi> [Robert Sanderson] Web Annotation Vocabulary

cwebber2: does the validator support extensions?>

sandro: it should

<eprodrom> I don't understand the issue

<bigbluehat> https://www.w3.org/TR/annotation-vocab/#as-orderedcollection

<Loqi> [Robert Sanderson] Web Annotation Vocabulary

<bigbluehat> mostly seen here https://www.w3.org/TR/annotation-protocol/

<Loqi> [Robert Sanderson] Web Annotation Protocol

<eprodrom> I think it will validate

<eprodrom> Has anyone tried it?

<bigbluehat> https://www.w3.org/ns/oa.jsonld <-- see stuff in here

<eprodrom> Subclassed?

bigbluehat: we subclass as orderderedcollection, and subclass ???

<sandro> eprodrom, are you using a json-ld processor, or just thinking of it as json?

<bigbluehat> "Activity Streams Collection [activitystreams-core] model is used for paging, as in-page ordering is an important requirement."

bigbluehat: and specifically this line is of purport

<eprodrom> Just as JSON

bigbluehat: it uses subclassOf

<eprodrom> This feels like a stretch for an implementation report

bigbluehat: because ldp's paging says you can only give so much...

<eprodrom> But I'd be happy to have it

bigbluehat: we need these things to not die if nobody else uses them

<eprodrom> bigbluehat: is there an implementation that we can do a report for, then?

bigbluehat: since we're depending on them from a vocab perspective the as2 vocab needs to make it all the way to PR for us to not hav eproblems

sandro: it wouldn't change implementations

tantek: you'd just have to copy spec text in

<eprodrom> So, I wanted to ask Arnaud a pointed question

<eprodrom> Can we expect implementation reports from any IBM products or projects?

arnaud: only one from jasnell

tantek: can you give a rough guess on when it would be done

arnaud: nop

tantek: could you ask?

arnaud: yes

<jasnell> I'll write up an implementation report for the node.js module I created that impls the spec

<jasnell> I'll do that within the next two weeks

sandro: IBM is probably not doing any more as2 stuff fwiw

<sandro> bravo, jasnell

<sandro> (really, I asked and Arnaud confirmed)

tantek: can you take implementation reports and put them in summary sometime mid/late october, that would be great
... we need to do PR transition calls
... so that sets expectations for AS2
... anything else about AS2 exiting CR?

rhiaro: did we talk about the validator? I've been filing issues and want to see them fixed

<sandro> eprodrom, you hear that?

<eprodrom> OK

<rhiaro> https://github.com/w3c-social/activitystreams-validator/issues

eprodrom: yes that's fine

<bigbluehat> https://github.com/w3c-social/activitystreams-validator

sandro: do you have a timeline eprodrom on addressing those issues?

eprodrom: let's see when I can get through them, most are pretty small, like having links

tantek: we don't need to discuss them righ tnow, but if you think you can address them by next week eprodrom, that would be great

eprodrom: so have the validator have these issues fixed by next week?

tantek: or at least some update on the issues

eprodrom: can do

<eprodrom> Validator update

<eprodrom> Got it

tantek: ideally all issues are fixed but that's not a reasonable request, but I won't ask it, but then we would know you can perform miracles
... I think that brings us to end of AS2
... so that brings us to group status, when we all become existential

sandro: I'm really impressed with the progress we made in these two days. I actually think we're on track, which is impressive
... we have a lot to do!

tantek: on that note, one thing we've discussed in previous meetings is narrowing types of actions we accept as we get closer to group close. So I think we said "try to bring to CR by this meeting-ish"
... I think by spirit of that, we're on track, based on everything we saw
... I think we should adopt a policy of doing no more rec-track working drafts

PROPOSED: No more adopting rec-track first public working drafts in this working group

<rhiaro> +lol

+1

<bigbluehat> +lol

<tantek> +1

<sandro> +1 (obviously)

<aaronpk> +1 lol

+lol

<csarven> +1 with a :)

RESOLUTION: No more adopting rec-track first public working drafts in this working group

<eprodrom> +q

<eprodrom> -q

<eprodrom> +1

tantek: this still leaves the door open to note-track working drafts and I think that's fine
... so if you want to merge namespaces or discover links and back off, those are potentially acceptable, no need to restrict till end of charter
... are you going to bring social web protocols to CR?

rhiaro: no

sandro: you can do rec-track primers
... are you going to do that?

rhiaro: maybe!

sandro: so one place it would get left off of is the proposed recommendation list for the advisory committee
... and it seems like having the social web protocols in the CR

tantek: I would like social web protocols in the PR transition request, and I would even say the PR WBS

sandro: I think WBS is "web based strawpoll"

rhiaro: I'm conflicted, if there's no problem with having no-normative content as rec track, great, but if people find it weird, I'm fine with a note

AnnBass: I wanted to ask if we agree that the goal is to understand how the specs work together?
... do we also agree that whatever format if rec/note/etc is somehow that document gets advertised/published/etc such that anyone who sees these specs sees that too

PROPOSED: We will move Social Web Protocols to a note, with the condition that all rec-track documents reference it informatively.

<cwebber2> +1

<tantek> +1

<aaronpk> +1

<AnnBass> +1

<rhiaro> +1

<sandro> +0 whatever

<eprodrom> +1

<csarven> +1

<rhiaro> unless I suddenly figure out how I can use it to take over the world

<eprodrom> That's fine

RESOLUTION: We will move Social Web Protocols to a note, with the condition that all rec-track documents reference it informatively.

AnnBass: should LDP link to SWP?

sandro: no it's shut down

AnnBass: ok

tantek: so I think we're done with that, the major suggestion is "what's next with the group"

AnnBass: there's lots more that can be done in the social web space... I hear we would not be easily recharter... I've suggested we move the social interest group to a new CG, and we start tossing around ideas there, and if there's interest/energy/etc, then we can move to a rec-track group etc

PROPOSED: We create a social web incubator CG and that we basically say we're creating it to at least incubate things that would have otherwise been developed in this group or the social web interest group

<csarven> ++ on the "blah blah"

PROPOSED: Somebody create a social web incubator CG and that we basically say we're creating it to at least incubate things that would have otherwise been developed in this group or the social web interest group

<tantek> +1

<csarven> +1

PROPOSED: AnnB will research creating a social web incubator CG and that we basically say we're creating it to at least incubate things that would have otherwise been developed in this group or the social web interest group

<AnnBass> +1

<tantek> +1

<AnnBass> oh ... not necessarily AnnB

+1 even if arnaud says I'm doing terrible things by proposing things that are not actionable via proposals

<AnnBass> cwebber2 melts down

<sandro> Really we mean: the group expects it work to continue in a Social Web Incubator CG

<eprodrom> Yes?

<eprodrom> +1

<aaronpk> +1

tantek: AnnBass, can you look into transitioning the federated social wg to this new CG?

AnnBass: yes

<aaronpk> +1 to what sandro said

<tantek> +1

<AnnBass> Evan: do you or Andreas have issue with closing the Fed Social Web CG?

+1

<csarven> +1

<eprodrom> AnnBass: I do not, but I can't speak for Andreas

<eprodrom> I barely know him

<AnnBass> ok .. I can try to find him

<eprodrom> Hooray!

SORTA-RESOLVED: AnnB will research creating a social web incubator CG and that we basically say we're creating it to at least incubate things that would have otherwise been developed in this group or the social web interest group

<eprodrom> Thanks all!

<AnnBass> I am happy to work on cleaning up Fed Social Web CG and moving that stuff to new Social Web CG

Arnaud1: I think it's clear that I don't have the bandwidth for this, so I'm resigning as co-chair

cwebber2: thank you for all you've done

everyone: *applauds arnaud for all his hard work*

<aaronpk> :applause:

<AnnBass> tons of thanks to Arnaud

tantek: meeting adjourned with 15 secs to go!

<eprodrom> THANKS Arnaud1 !

<csarven> all++

<Loqi> all has 1 karma

<tantek> trackbot, end meeting

arnaud++

<Loqi> arnaud has 36 karma (34 in this channel)

Summary of Resolutions

1. Add source field to AP as at risk per proposal in activitypub/issues/107
2. We'll give until October 11 to find out if we can put these in AS2 vocab. If we can do that, we will. If not, I'll use AP's own namespace.
3. add a section to SWP describing the likely potential for server-to-server heavy load from discovery requests and approaches to mitigating
4. publish new WD of LDN including fixes resolved by the WG today
5. publish new WD of post type discovery, with the highlight of the issue regarding the type in the introduction
6. Accept Proposal-2 from https://github.com/w3c/activitystreams/issues/370, being clear we're committed to keeping stable things stable
7. Remove SHOULD from name/nameMap on general Object and add SHOULD to name/nameMap to Article.
8. Return distinction between "user entered or otherwise significant name" and "text fallback" and shift SHOULD from meaningful name to text fallback.
9. Take Pubsubhubbub to FPWD from ED with the fix of the SHA change
10. Use shortname of pubsub for shortname for now
11. Close pubsubhubbub community group with "mission accomplished", draft incubated, it's now a rec-track working draft as part of socialwg.
12. No more adopting rec-track first public working drafts in this working group
13. We will move Social Web Protocols to a note, with the condition that all rec-track documents reference it informatively.