See also: IRC log
<tantek> scribenick: AnnBass
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
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
RESOLUTION: Add source field to AP as at risk per proposal in activitypub/issues/107
tantek: There were no objections
arnaud: You sai dyesterday from a process point of view you can do the resolution liek this which is fine, I still think it's good to have the proposal listed in IRC before you do that
tantek: I called for objections, didn't get minuted..
sandro: for people who are remote
<rhiaro> TODO: add proposal to minute above ^^^^^^^^
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 intesne
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?
*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
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
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 ben 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
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 opinoion
... 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 soething (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 tes tbecause 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 lable it, *put a name there*
<rhiaro> but not that everyone is required ot 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 thin'g
... 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: tryign 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 ats
ummary
... 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 isntead of summary because we might just push the same problem onto summary ifwe use that
aaronpk: then if you use property
b 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", "type": "http://abc/thing", "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"
<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
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, si 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
<rhiaro> trackbot, please generate minutes
<trackbot> Sorry, rhiaro, I don't understand 'trackbot, please generate minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<rhiaro> trackbot, generate minutes
<trackbot> Sorry, rhiaro, I don't understand 'trackbot, generate minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
tantek: put september 27th as due date
<tantek> trackbot, pointer
<trackbot> Sorry, tantek, I don't understand 'trackbot, pointer'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
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
+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.
+1
<tantek> +1
<aaronpk> +1
<eprodrom> http://content-img.newsinc.com/jpg/1459/24779720/4518170.jpg?t=1367337600
<eprodrom> +1
http://skepticism.org/images/jreviews/tn/tn_6156_Bush_mission_accomplished.jpg
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
/me -_o_-
/me
oops
<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 😂
https://www.w3.org/wiki/images/c/c9/2016-09-23-socialwg-group-animated.gif
<eprodrom> That is awesome
<Loqi> [@bigbluehat] Yeah #TPAC2016 https://www.w3.org/wiki/images/c/c9/2016-09-23-socialwg-group-animated.gif Pretty sure @SocialWebWG is done with my help... ;) (http://twtr.io/1HL17LToUWw)
<Loqi> [@dustyweb] .@SocialWebWG is taking federated names and getting things done https://www.w3.org/wiki/images/c/c9/2016-09-23-socialwg-group-animated.gif (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 https://www.w3.org/wiki/images/c/c9/2016-09-23-socialwg-group-animated.gif 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
eprodrom, I *might* be able to
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 Arnaud1 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 recommendatoin 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.
+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)
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/partially/we've seen other pumpio implementations/ Succeeded: s/seems OK/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/ Succeeded: s/You said/aaronpk said/ FAILED: s/compared to the first W3C spec I implemented (OWL Full) so my perspective may be a bit different// Succeeded: s/compared/compared to the first W3C spec I implemented (OWL Full) so my perspective may be a bit different/ Succeeded: s/wait/give/ Succeeded: s/Option 1/Preference 1/ Succeeded: s/Option 2/Preference 2/ Succeeded: s/???/Web Annotations WG/ Succeeded: s/hte/the/ Succeeded: s/shoulld/should/ Succeeded: s/dfeinitely/definitely/ Succeeded: s/PROPOSE/PROPOSAL/ Succeeded: s/tantek/sandro/ Succeeded: s/pubisher/publisher/ Succeeded: s/sandro,/sandro:/ Succeeded: s/2:/2,/ Succeeded: s/things/spec text/ Succeeded: s/recharted/recharter/ Succeeded: s/I think I'm skeptical...// Found ScribeNick: AnnBass Found ScribeNick: rhiaro Found ScribeNick: aaronpk Found ScribeNick: rhiaro Found ScribeNick: rhiaro Found ScribeNick: rhiaro Found ScribeNick: cwebber2 Inferring Scribes: AnnBass, rhiaro, aaronpk, cwebber2 Scribes: AnnBass, rhiaro, aaronpk, cwebber2 ScribeNicks: AnnBass, rhiaro, aaronpk, cwebber2 Default Present: rhiaro, cwebber, tantek, KjetilK, aaronpk, tsyesika, Benjamin_Young, csarven, newton, Arnaud, Ann, Bassetti, AnnBass, ben_thatmustbeme, david_wood, eprodrom, wseltzer, lol Present: rhiaro cwebber tantek KjetilK aaronpk tsyesika Benjamin_Young csarven newton Arnaud Ann Bassetti AnnBass ben_thatmustbeme david_wood eprodrom wseltzer lol WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 23 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/23-social-minutes.html People with action items:[End of scribe.perl diagnostic output]