Social Web Community Group Teleconference

31 Jan 2018

Attendees

Present: ajordan, aaronpk, cwebber, eprodrom, ben_thatmustbeme, cwebber2
Regrets
Chair: aaronpk
Scribe: cwebber2

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

ActivityStreams open issues / errata

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

activitypub-mock

<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

question about webmention spec

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

Summary of Action Items

Summary of Resolutions

[End of minutes]

SocialCG/2018-01-31/minutes