<scribe> scribe: cwebber2
<ben_thatmustbeme> need to let w3c know to change that so it says the correct Meeting: line
aaronpk: we seem to be missing meeting minutes for last two weeks
cwebber2: seeing if we had it via trackbot... doesn't look like it
aaronpk: nope
... ajordan converted the minutes from 2 meetings ago from
their IRC logs, maybe they can do that again? we'll just have
to bump that to next time he's available
... I don't think there's any more we can do on that front, so
let's move on
aaronpk: I believe we've had conversation on this on the past
cwebber2: yes we've at least agreed that the socialcg continues work
aaronpk: and eratta processing
cwebber2: can we also say horray the spec work is done?
aaronpk: yes, congrats all
<ben_thatmustbeme> congrats all
eprodrom: yes! i think everything is done
aaronpk: yes we've solved everything
eprodrom: yes and I think today was the last day of the socialwg right?
aaronpk: technically true
... so with the understanding that we will be continuing work
on specs here, including issues as they come in, what's the
policy on publishing new editor's drafts
eprodrom: yes this is Evan, I
think we're not supposed to edit these at all... that's why we
have eratta sections, there are errors on the eratta pages,
that's it... the doc is supposed to be carved in stone
... whether we build extensions that happen, or things that
change in documents, but I think having any... since the main
document on w3.org can't change, I don't think we should be
planning anything unless there's a .1 version, energy should go
into errata
<eprodrom> I just muted, thanks
<ben_thatmustbeme> thanks, was getting feedback
cwebber2: I agree, we *could* do 1.1 type things but we need a lot of justification, json-ld is doing that after a few years but it's a lot of effort... we should focus on extensions and eratta
aaronpk: yes I agree
eprodrom: we do have a lot of documents that can be edited, for instance as2.rocks, micropub.rocks, the test suites which can be edited as needed... for AS2 there's a lot of example documents which are fair play for editing those... I think it's really the big docs that go up on the big site which we need to worry about leaving carved in stone
aaronpk: yes there's always room
for improvement on examples and tests
... I did most of the work on the examples and test suites but
there's always more that can be improved
cwebber2: would we want to make certain items official work items? eg anti-abuse and account migration and etc
aaronpk: we should at least document what we're currently working on, eg putting up on the wiki
eprodrom: I think that Chris you just came up with like 3 items, I think these are going to be implementation issues... they're things where you're not going to have a standardization process, people go out and build it. for things like account migration, I think all the building blocks are there already. or global person search... everything you need to make that work exists, so it really comes down to people writing the software and building the
systems to do it. if there are interop issues in the future it makes sense for standardization, but I don't think they require a standards doc
aaronpk: I agree, these kinds of
things are not things we should try to standardize before
anything is implemented
... we should try to implement and see what can be
implemented
... the three you mentioned are pretty big, and I've got
several which are big things to do... we've got a lot of
groundwork to cover based on the systems we put out there
eprodrom: maybe one thing we could do is RFI for "here's something I'd like to see implemented" and see discussions around those requests
<eprodrom> RFI = request for implementation
aaronpk: that's a great idea and something to put on the wiki
<eprodrom> https://www.w3.org/wiki/SocialCG/RFI
cwebber2: are we mostly seeing the SocialCG at this point as the extensions, errata, and community builder support group?
aaronpk: sounds like a good characterization
eprodrom: sounds reasonable to me
cwebber2: I'm happy understanding that as the general direction then too
<ben_thatmustbeme> +1
aaronpk: cool, in that case it sounds like we have a good idea of a path forward... Chris, do you want to take on an action item to add your list of RFIs for lack of better term to the wiki page?
cwebber2: should we namespace it under SocialCG/RFI/foo?
<ben_thatmustbeme> +1 to front page
<ben_thatmustbeme> unless it gets huge
aaronpk: let's keep it flat, we could link to SocialCG/RFI
cwebber2: you made a good point about it being front-and-center, maybe just put it on the front page?
aaronpk: let's put the content as
bullet points on the bullet page, and specific details can go
on SocialCG/RFI
... anything else on this before we move on?
<eprodrom> nope
eprodrom: for AS2 we have around
25 open issues right now... some of them are backed up almost a
year... some are relatively recent, which is good which means
people have been paying attention to the document
... if I were to classify what these issues are I would say
they probably break down into 4 buckets: 1) problems with the
JSON-LD schema document... I think I'm very reluctant to mess
around with that since publication (I'm reluctant to mess
aroudn with it at all but am glad rhiaro is)
... I think it's probably ok to make corrections to it but I'm
not sure
... 2) problems with example files, specifically files in the
test suite... as far as I'm concerned they're wide open for
editing
... those two are relatively easy to deal with
... 3) there are clear errors in the main specification
documents, for those I think we write up errata and add them to
the errata page... relatively easy
... 4) problems with clarity in the spec... when can you use
items vs orderedItems... that's a point where it's not really
an error in the document, it's something readers have a harder
time understanding
... I guess my feeling would be, that is something we write
other documents around
... we write other web pages, wiki pages, etc
... not sure that goes in errata
... that's how I'm kind of looking at these open issues...
we'll see how it goes from there
... I'm a little bit concerned about the ones... I think the
basic thing is getting the errata and getting the changes to
the json-ld schema and example docs... once we get into the
clarity things, that's external documents not part of the
spec
<Zakim> cwebber, you wanted to talk about context extensions
cwebber2: one thing to know is we're now versioning json-ld contexts (especially important if doing linked data signatures if having extensions)
eprodrom: that's specifically for extensions?
cwebber2: yes that's the
motivator
... we agreed on this in the SocialCG that we would version
things so that if a new term was added, signatures wouldn't
break
<eprodrom> Great
eprodrom: that seems like a bad idea, we voted down versioning. also doesn't that mean that a versioned Person would be different than the next Person?
cwebber2: versioning vocabulary is different than versioning contexts... we're not changing the vocabulary, they point to the same Person
eprodrom: we still don't want the context to change much, it's supposed to be fairly stable and a slow-moving process
cwebber2: extra context to the context stuff: https://github.com/w3c-dvcg/ld-signatures/issues/9
<Loqi> [cwebber] #9 LD Signatures and json-ld contexts which grow
<ajordan> can we just say, let's not touch contexts until we resolve this?
<ajordan> maybe next week so we can loop in sandro
eprodrom: it sounds like this horse is out of the barn... but can we discuss this
cwebber2: let's pull in sandro, in the meanwhile please read this issue
eprodrom: sure
... I'm a bit frustrated that we voted in the SocialWG and
neither of the original editors voted on this
... but I guess I live with it... I guess we'll use this
versioning system from now on
cwebber2: we were trying to move forward with what the SocialWG agreed on, but I guess we either had a misunderstanding or made a mistake
ajordan: sorry to show up late... so I was reading some of the earlier IRC logs... what exactly am I doing for the minutes?
aaronpk: we weren't sure of the state of the missing minutes from before... I know you posted some of them, but last meeting's was not included in that?
ajordan: it should have been
aaronpk: oops I misread the wiki
ajordan: previous two should be there
aaronpk: oh yep, you're right... we can resolve that agenda item
ajordan: great, thanks
aaronpk: looks like someone added a new topic item
eprodrom: I added a topic for a software item, but if it's the last thing I'm happy to discuss it
<eprodrom> https://gitlab.com/evanp/activitypub-mock
eprodrom: awesome! so based on the work in tags.pub and places.pub, in particular in testing that software, I found myself needing a test activitypub server. instead of building ad-hoc mockups which I did initially, I ended up putting together a mock which implements most of activitypub. It currently covers all the major endpoints, I'm gradually workign all the way through... doing the different activity types, as well as across federation.
currently does federation with http signatures, it's mostly a process of getting it to do the rest of the commands. I've started integrating with the servers I've done, though I think it may be useful for other software developers who want to test their other client to server and server to server implementations. Only useful for nodejs users, but I think it would be a useful pattern for people doing activitypub
aaronpk: sounds useful!
cwebber2: yes very cool
ajordan: I agree
<ajordan> https://www.w3.org/TR/webmention/#avoid-sending-webmentions-to-localhost
ajordan: so there's this section... over the winter break I went to implement lazymention, and the only thing we really dealt with was don't send things to localhost. I'm unclear on what's the best way to determine localhost... is it to just look at the subnet mentioned in that section? Seems too brittle but I'm not sure... how do you determine if an IP address is "local"?
aaronpk: easiest way is to look at "localhost", but anyone can make a domain name that points at a loopback address, so strict check is to do DNS check first and then do lookup
cwebber2: just as an aside, those confused deputy attacks scare me
eprodrom: just as an aside,
nearly every unit test seems to run on localhost... how do
folks unit test things for this prohibition? I just haven't
bothered so far
... does anyone have a good pattern for testing this stuff
locally?
ajordan: well... I don't know if
it's a good pattern, one thing you can do is you can use
libraries that overload Node's `require()` to overload
something that does a dns lookups and return a safe
result
... you could do it, I haven't bothered
cwebber2: you could set up the localhost server to only accept safe/mundane input and configure it... the safest route is to do it over a unix domain socket, though that isn't supported easily
<ajordan> FWIW Node's HTTP module does Unix domain sockets out of the box
eprodrom: yes I think a runtime flag that allows for connecting to localhost... though your test coverage is kind of left out there, you never test that that thing actually works
cwebber2: I assume by that thing you mean testing that you don't connect to localhost, since you are?
eprodrom: yes exactly, it's a minor point but it's a head scratcher for me
ajordan: I might write an npm
module to determine "is this in that IP subnet" and that could
go through the effort of stubbing out the dns resolution for
that?
... test once use everywhere
eprodrom: I think other things you can do such as setting up a virtual host, etc... that thing can connect to a hostname rather than localhost, etc... it's just a funny thing that doesn't seem to match well with typical unit hosting practices
ajordan: in pump.io we (and by we I mean eprodrom 5 years ago) we have a scriptname that puts things in /etc/host and you can get local domain names and expect them to fail? I dunno....
eprodrom: it's so terrible
ajordan: it came in handy, but you don't want to know the details
<eprodrom> Agreed!
ajordan: I was debugging soemthing with dialback.. it's a scary house of funhouse mirrors and serial killer clowns
<ajordan> sounds great
cwebber2: should we try to pull in sandro and tantek for an upcoming meeting?
eprodrom: we should have the conversation, I think the main thing is compatibility, if the main reason we have to compare things is the context string I want to make sure we're doing it for the right reasons and that it works
<eprodrom> Thanks!
aaronpk: at the top of the hour, meeting adjourned!
<aaronpk> don't forget to present+ for the minutes
trackbot, end meeting
<aaronpk> 🎉
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Social Web Working/Social Web Community/ Succeeded: s/a node require/Node's `require()`/ Succeeded: s/gary/scary/ Succeeded: s/funhouse killers/funhouse mirrors/ Default Present: ajordan, aaronpk, cwebber, eprodrom, ben_thatmustbeme Present: ajordan aaronpk cwebber eprodrom ben_thatmustbeme cwebber2 Found Scribe: cwebber2 Inferring ScribeNick: cwebber2 Found Date: 31 Jan 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]