melodymy calendar says it's in an hour, but i likely won't be able to make it either way i've been sick for over a week and i need to get back on top of my other commitments
cwebber2puckipedia: nightpool: rhiaro: Gargron: ben_thatmustbeme: jaywink: other usual suspects, just in case you wanted to show up, SocialCG meeting is happening now
cwebber2aaronpk: 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
cwebber2aaronpk: 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
cwebber2eprodrom: 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
cwebber2eprodrom: 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
cwebber2cwebber2: 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
cwebber2eprodrom: 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
cwebber2eprodrom: 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
cwebber2aaronpk: 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
cwebber2aaronpk: 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?
cwebber2eprodrom: 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
cwebber2eprodrom: 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)
cwebber2eprodrom: 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
cwebber2eprodrom: 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
cwebber2eprodrom: 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
cwebber2cwebber2: one thing to know is we're now versioning json-ld contexts (especially important if doing linked data signatures if having extensions)
cwebber2eprodrom: 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?
cwebber2aaronpk: 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?
cwebber2eprodrom: 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.
cwebber2currently 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
cwebber2ajordan: 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"?
cwebber2aaronpk: 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
cwebber2eprodrom: 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
cwebber2ajordan: well... I don't know if it's a good pattern, one thing you can do is you can use libraries that overload a node require to overload something that does a dns lookups and return a safe result
cwebber2cwebber2: 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
cwebber2eprodrom: 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
cwebber2ajordan: 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?
cwebber2eprodrom: 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
cwebber2ajordan: 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....
cwebber2eprodrom: 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
tantekre: errata / maintenance, we (SocialWG) agreed that SocialCG is a good place (option) for doing maintenance on SocialWG specs, *however* we ultimately left it as the (particular spec) editor's choice as to where to do maintenance, with SocialCG as a nice friendly option.
tantekthe fact that no one did (or could) point to a "best practices for JSON-LD context maintenance" is indicating perhaps a gap in understanding of how JSON-LD is supposed to work. brainstorming it in a telcon is likely not the most productive use of time. (note: I don't have the answer either, but I'm just observing that not knowing then making it up is not a good methodology, when you know there are "experts" you could ask first)
cwebber2well... json-ld contexts are easy if you don't change them, and they're even easy if you do change them append-only... it's only once you change them, sign documents with them, and also cache the results :)
tantekcwebber2: given the history of Google metadata/vocab dictionary efforts, it wouldn't surprise me if in a few years they abandoned schema.org for something else
Loqi[sandhawke] I've now implemented this so people can experiment:
https://www.w3.org/ns/activitystreams-history/
contains all (eight so far) versions of the jsonld version of the namespace document, with cache control max-age 1 year.
It's generated by a s...
cwebber2melody: well the decisions I'm referring to happened far before this meeting, which is why it was heated... it was a surprise to Evan, who was co-editor of activitypub :)
cwebber2<cwebber2> 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<cwebber2> cwebber2: versioning vocabulary is different than versioning contexts... we're not changing the vocabulary, they point to the same Person
melodyi just didn't scroll far enough up -- i missed a lot of backscroll because my client thought there was less unread content than there actually was, i guess i can't fully trust the marker it uses to track what I have and haven't seen yet
cwebber2I'll note that I did try to bring up towards the end of the SocialWG "we need to talk about extensions" and the response I got was "we already discussed AS2 extension mechanism to death, read what we wrote"... so I did, and we had various SocialWG participants present in that SocialCG meeting
cwebber2but the question is: should AS2 be fairly liberal about including new extensions as an append-only system, or should we push for extensions to be in a separate contextt
Loqi[msporny] @cwebber you've basically covered all of the options.
The short advice to developers is: make sure all of your properties are in the context when you sign or you're in for a world of pain. We're going to be adding a feature to the reference imple...
cwebber2melody: the core idea is that json-ld allows two things: a) a mechanism for unambiguous, extensible vocabulary in json documents, and b) a way to have developers work with comfortable local "plain json" tooling, while also being able to tap into the richer world of linked data if they want to
eprodrom Hi all
aaronpk yeah our summer time was still 8am pacific 11am eastern https://www.w3.org/wiki/SocialCG/2017-06-07
ben_thatmustbeme can't join on mumble, but can watch on irc
RRSAgent logging to https://www.w3.org/2018/01/31-social-irc
cwebber2 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
tantek the fact that no one did (or could) point to a "best practices for JSON-LD context maintenance" is indicating perhaps a gap in understanding of how JSON-LD is supposed to work. brainstorming it in a telcon is likely not the most productive use of time. (note: I don't have the answer either, but I'm just observing that not knowing then making it up is not a good methodology, when you know there are "experts" you could ask first)
csarven I don't have the full context here, and pardon me if this is non-applicable, but there is https://json-ld.org/spec/latest/json-ld-api-best-practices/ .. I suspect that will incorporate whatever is discussed above.
ajordan tantek: were you thinking of https://www.w3.org/wiki/Socialwg/2017-12-05-minutes#Errata?
bigbluehat is coming late to this party...but...
Loqi [sandhawke] I've now implemented this so people can experiment:
https://www.w3.org/ns/activitystreams-history/
contains all (eight so far) versions of the jsonld version of the namespace document, with cache control max-age 1 year.
It's generated by a s...