Meeting log: "Meeting Chat" @ Sunday 2nd of October 2016

[20:03:02] <Pretorian> Welcome to DCNF monthly meeting, it is 2016-10-02.
[20:03:06] <Pretorian> For simplicity sake, I will be the chairman and Crise has agreed to act as secretary.
[20:03:10] <Pretorian> What we do need is a head count, so just state your names. 
[20:03:12] <Pretorian> Pretorian
[20:03:18] <poy> poy
[20:03:19] <cologic> cologic
[20:03:24] <Crise> Crise
[20:03:30] <Pretorian> All right
[20:03:42] <Pretorian> There's a few items from the last meeting;
1) Write HTTPS article. (cologic/klondike)
2) E-mail to EFF/GNU about license for the website (Pretorian)
3) Finalize donators list (Pretorian)
4) ASCIIDoc migration (away from) (Crise)
[20:03:50] <Pretorian> Item 1) HTTPS
[20:03:54] <Pretorian> This is completed, yes?
[20:04:33] <Pretorian> At least the technical part.
[20:04:42] <Crise> The important part anyways, however, the SSL settings on cloudflare have been reverted to a more permissive set, cologic can explain that
[20:04:58] <Pretorian> I've asked cologic to write some more non-technical part, and there was a resposne, but I don't remember it offhand.
[20:05:19] <cologic> Yes, (1) for Crise, there's still HTTPS the whole way through.
[20:06:01] <cologic> However, CloudFlare is not validating dcbase.org's certificates because not all the subdomains serve Let's Encrypt-compatible challenge responses.
[20:06:21] <Crise> which are missing that?
[20:06:37] <Crise> all subdomains should be serving them
[20:06:49] <cologic> Last I recall, builds.dcbase.org didn't -- I haven't checked within the last couple of weeks though.
[20:07:09] <cologic> So if there have been recent changes, then it might be safe to re-enable strict HTTPS.
[20:07:53] <Crise> no recent stuff
[20:08:14] <Crise> do they need to be served on both http and https?
[20:08:40] <cologic> For Pretorian, yes, the two suggestions were (a) why HTTPS, and (b) why Let's Encrypt. It's looking increasingly like (a) is going to be a foregone conclusion with Firefox and Chrome pushing it more aggressively. (b) seems less important, if only because Let's Encrypt has the mindshare already.
[20:08:56] <cologic> They need to be served on HTTP for it to work most reliably.
[20:09:07] <Crise> that they are
[20:09:42] <cologic> Okay, I'll look at that again and check which, if any, subdomains still block strict CloudFlare SSL.
[20:09:59] <cologic> If none, I'll enable strict SSL.
[20:10:06] <Crise> I know what is wrong with it
[20:10:38] <Crise> its an option on cloudflare's side I tried to enable to enforce more https traffic
[20:12:45] <cologic> Pretorian: there may be a place for a more modest, not 'why should the world use HTTPS', which is well-covered, but a briefer 'why have DCNF and related sites used HTTPS', which is something I can more directly address and may provide the context you're looking for while not being entirely redundant with a dozen other articles on the topic.
[20:13:02] <Pretorian> cologic: Yeah, that'd be greatly appreciated.
[20:13:04] <cologic> Crise: okay, and what happened?
[20:13:50] <cologic> Pretorian: okay, I'll write a companion post along those lines.
[20:14:03] <Pretorian> I can agree that a "why HTTPS" is probably too simple, I just found your post on the blog to be almost too technical (although I certainly understand its audience's request regarding it).
[20:15:14] <cologic> Sure, and it is also very specific to the setup we use -- little to no generalization value to a lot of other configurations.
[20:15:23] <Pretorian> Exactly.
[20:15:39] <Crise> cologic: I added a page rule to force https on cloudflare... that obviously tries to force it on the challenges as well... disabled now
[20:17:29] <Pretorian> All right, maybe we can move on, and you can possibly coordinate/check after the meeting with settings?
[20:17:44] <cologic> Alright.
[20:17:44] <Pretorian> (Trying to keep up the pace for the meeting.)
[20:17:59] <Pretorian> All right, next item.
[20:18:05] <Pretorian> 2) e-mail to EFF;
[20:18:34] <Pretorian> Not done, sorry. I'm hesitant if I'll have the time to do this in a forseeable future, but do poke me to make a stab at it.
[20:18:47] <Pretorian> Let's move on.
[20:18:51] <Pretorian> Item 3) Donators list
[20:19:20] <Pretorian> List is complete, but there is an issue in a) getting it commited to Git and b) finding the appropriate for tables in the file.
[20:19:54] <Pretorian> Will re-base Git (or just throw out everything, whatever's simpler) later this evening and continue from there.
[20:20:02] <Pretorian> So this should be completed today.
[20:20:16] <Pretorian> Next item.
[20:20:21] <Pretorian> 4) ASCIIDoc migration.
[20:20:31] <Pretorian> Crise, have you looked into this more? 
[20:20:55] <Crise> can't be done automatically... asciidoc is basically the format you can convert to but not from
[20:21:08] <Crise> using automated tools that is
[20:21:13] <Pretorian> Hm, ok.
[20:21:17] <poy> (sorry I don't have the context,) which docs is this about, and what are the motivations?
[20:21:29] <Pretorian> poy: ADC/NMDC docs.
[20:21:47] <poy> ok, to markdown or latex I guess?
[20:21:53] <Crise> motivation: asciidoc can not be generated through php frontend
[20:21:53] <Pretorian> To markdown.
[20:22:31] <Crise> basically anything that has php parser would work...
[20:22:40] <Crise> for my purposes :)
[20:22:51] <poy> surely you can produce some HTML from asciidoc?
[20:23:17] <Pretorian> The current docs are ASCIIDoc generated HTML pages.
[20:23:27] <Crise> not without executing shell commands... which are slow in php
[20:23:38] <poy> ah ok.
[20:23:47] <Crise> not to mention dangerous
[20:24:38] <Pretorian> So what's the simplest approach in migrating to ASCIIDoc? Manual and just attempt to see what breaks/doesn't work?
[20:24:44] <Crise> also, curiously there isn't even automated conversion between most formats... pandoc for instance can produce asciidoc but not read it
[20:24:45] <Pretorian> from ASCIIDoc*
[20:25:52] <Crise> based on what I tried the easiest way seems to be manual conversion... the more round about the way you try and automate it is the more problems
[20:26:15] <Pretorian> All right, will do so.
[20:26:45] <Pretorian> All right, that's all items from the previous meeting.
[20:26:47] <Crise> basically if we had really good html to markdown converter and an asciidoc output without all the superflous styling information, it might be possible to do an automated conversion from html to markdown
[20:27:12] <Pretorian> Crise: Does such a converter exist?
[20:27:58] <Crise> html to markdown yes... whether it is good enough for docs as complex as the adc ones I do not know... but I used such converter to migrate the content from static site to markdown
[20:28:08] <Crise> dcbase.org that is
[20:28:29] <Pretorian> Can't we just use that one then?
[20:28:46] <Crise> I don't know how to produce an unstuled html from asciidoc
[20:29:10] <Crise> it has too much excess markup to work well as it is (CSS references etc)
[20:29:20] <Crise> *unstyled
[20:30:12] <Pretorian> Hm, ok.
[20:30:17] <Pretorian> Perhaps a manual approach is easier then.
[20:30:33] <Pretorian> All right, let's move on.
[20:30:39] <Pretorian> That's all items from the previous meeting.
[20:30:43] <Pretorian> Does anyone have any additional items?
[20:30:55] <cologic> I do not.
[20:31:01] <poy> well, are we ready to welcome some projects in? :)
[20:31:17] <Pretorian> Pretorian-1) NMDC URI scheme
[20:31:37] <Crise> Crise-1) Project setup
[20:31:48] <Pretorian> <I'll leave some time for people to state their items> 
[20:32:09] <poy> poy-1) projects to invite in
[20:33:02] <Pretorian> Let's start with poy's item since he brought it up first.
[20:33:07] <Pretorian>  poy-1) projects to invite in
[20:33:24] <Pretorian> We already have the NMDC and the ADC project added, currently.
[20:33:44] <poy> open discussion, I have no particular opinion here but this will make the org move forward.
[20:34:12] <Pretorian> There is currently <https://gitlab.com/dcnf/nmdc-code>, <https://gitlab.com/dcnf/nmdc-web>, <https://gitlab.com/dcnf/adc-web> and <https://gitlab.com/dcnf/adc-code>.
[20:34:37] <Crise> the web repositories should still be empty, my topic will cover that a bit
[20:34:40] <Pretorian> Any other particular projects you had in mind that should be included?
[20:34:50] <Pretorian> (right now at least)
[20:35:46] <poy> actual client / hub software - as a start, we could prepare some invite message with benefits the DCNF provides to nudge these existing projects into joining in?
[20:36:09] <Pretorian> There is also <https://www.dcbase.org/affiliated_projects>
[20:36:46] <Pretorian> An invitation message is certainly nice. 
[20:37:02] <Pretorian> How/which software did you have in mind?
[20:37:45] <poy> not sure which ones are the most active these days...
[20:38:43] <Pretorian> In my opinion, most "utilities" software should definitely fall into the category of an affiliated project, but I don't think e.g. DC++ or AirDC++ falls so readily into it. 
[20:38:43] <Crise> as for benefits... outside of allowing people to push content on the website which we can do, the org doesn't currently have the resources to be a miniature SF unfortunately...
[20:39:18] <Pretorian> Some things I think we can certainly do; provide certificate management and website management.
[20:40:54] <Pretorian> FreeTiger is such a utility program.
[20:40:59] <Crise> websites we can do... as long as they are deployed in a way that doesn't involve giving direct access to the OVH server to everyone that asks for it
[20:41:22] <Pretorian> Yeah, certainly OVH access should be restricted.
[20:41:28] <Crise> ie. something like what the dcbase.org uses right now... or static site generators etc.
[20:42:07] <cologic> And FreeTiger's web hosting situation actually does illustrate some value, potentially, of being more explicitly DCNF-affiliated, should klondike desire that -- the current website is nigh-undiscoverable unless one already knows of FreeTiger.
[20:42:53] <Pretorian> In general, I think there's two types of affiliated projects; 1) A utility or backbone project (hublist software falls into this category) and 2) software that wish to have their website etc hosted on a DC page (e.g. DC++).
[20:43:06] <Crise> agreed, but that depends on klondike
[20:43:22] <Crise> ^ cologic
[20:43:22] <cologic> Absolutely.
[20:43:26] <Pretorian> 1) is essentially "without these programs, the entire ecosystem crumbles".
[20:43:52] <Pretorian> (but maybe I'm too optimistic/harsh?)
[20:45:45] <Pretorian> poy: Can you make a list of existing software that you think should be in DCNF as an affiliated project?
[20:46:21] <Crise> that would be interesting yes, if also in part to see how different people define an affliate project
[20:46:26] <poy> not sure I'd be the best for that. :P
[20:47:31] <Crise> having said that... the issue with most client projects becoming affiliate projects, although there is nothing stopping them, the reasons the organization could be benefitical for them are limited
[20:48:21] <Pretorian> For phone applications I can forsee a scenario where the org pays for a phone distrubtion certificate and affiliated projects can simply use that.
[20:48:26] <Crise> because they have an already established infrastructure and websites... so us providing that is of little import to such projects
[20:49:00] <Pretorian> So not necessarily providing infrastructure but rather a "sticker" that says "trusted".
[20:50:22] <cologic> There's some other value, potentially, in preservation as well -- projects that are useful to have a record of, but precisely due to the historical ephemeriality of maintenance of many DC projects, might otherwise simply disappear modulo archive.org or similar less trustworthy archives.
[20:50:34] <Pretorian> cologic: Indeed.
[20:50:43] <Pretorian> cologic: It is also why I've attempted to gather old forums.
[20:50:53] <Pretorian> And repos.
[20:51:17] <cologic> Which has been quite valuable I think, yes.
[20:52:59] <Pretorian> I'd like to get e.g. the old Bugzilla (for DC++) in place and the Swedish DirectConnect.se forum (don't have the database unfortunately) up on the site.
[20:53:21] <cologic> Seems worthwhile if they're available.
[20:54:31] <Crise> mind you the problem with hosting actual old software is security... so it would be benefitical if they were either a static snapshot or something where the underlying software can at least be updated
[20:55:01] <Crise> ie. old version of bugzilla probably wouldn't run on the server even
[20:55:27] <Pretorian> Crise: That'd certainly be fine for me.
[20:55:43] <Pretorian> The issue, I guess, is getting the snapshot up and running at all? Dunno.
[20:55:51] <Pretorian> For Bugzilla I have the actual database.
[20:56:14] <Crise> the dcpp forums are a headache as it is... right now they are "working" but they shouldn't be (as in that version of phpbb doesn't support php7 anymore than the dcbase forums does at the moment
[20:57:45] <Crise> yeah when it comes to php software that is precisely the issue... running php versions in parallel is a huge pain (unless you are using something like apache and cpanel)
[20:58:10] <Pretorian> Is it possible to create a snapshot of a such a database/website`?
[20:58:31] <Crise> you would still need to host and crawl it somewhere
[20:59:04] <poy> one solution to host old stuff is a VM with a snapshot reset every month or so...
[21:00:12] <cologic> Is there a timeline or roadmap on PHP7 support?
[21:00:20] <cologic> It seems like many people would want it.
[21:00:29] <Crise> by the end of the year for phpbb
[21:01:06] <Crise> the server is running it (although by accident :P) which is why the forumns are offline
[21:03:09] <Pretorian> All right, we've gone off track a bit, I think.
[21:03:44] <Pretorian> poy: Please make a list of projects you'd like to see included as an affiliated project. <https://www.dcbase.org/affiliated_projects> have additional suggestions
[21:03:55] <Pretorian> poy: It doesn't have to be an existing project, I guess.
[21:04:01] <Pretorian> We can create one
[21:04:10] <Pretorian> poy: Your list has to include at least 1 item. ;)
[21:04:17] <poy> sure, will do!
[21:04:24] <Pretorian> Great, let's move on.
[21:04:37] <Pretorian> Let's do Crise's item since it's kind of related.
[21:04:55] <Pretorian>  Crise-1) Project setup
[21:05:00] <Pretorian> Crise?
[21:05:24] <Crise> Sure, so for that the issue is really minimizing manual tasks
[21:06:40] <Crise> I mean for anything that goes on dcbase.org (the main site) we can just accept merge requests (aka pull requests), however, for projects such as adc and nmdc that use their own subdomain some degree of manual setup can not be avoided
[21:06:50] <Crise> see: certificates
[21:08:32] <Crise> additionally managing sub projects through git is annoying (submodules are weird), the important bit is that I don't have to do changes in triplicate or more going forward if more project want to use dcbase.org system for site management
[21:08:39] <Crise> (discuss, phone)
[21:09:56] <cologic> If it's not clear from my blog post, the main marginal administrative overheads of new subdomains are (a) adding a subdomain to the certificate request; and (b) ensuring the web server at that subdomain correctly serves the challenge responses.
[21:10:06] <cologic> The rest amortizes over all subdomains.
[21:10:35] <cologic> (a) is easy. (b) can be trickier.
[21:10:40] <Pretorian> Can we make sure that adc.sf.net points to adc.dcbase.org?
[21:10:53] <Pretorian> I don't remember what is/isn't possible with SF.
[21:10:59] <Crise> it can be done
[21:11:08] <Pretorian> So we don't lose the linking.
[21:11:22] <Crise> don't ask me how though... I am guessing htaccess
[21:11:58] <cologic> There are also variations on (semi)permanent HTTPS redirects, which, yeah, can be implemented via .htaccess.
[21:12:37] <cologic> e.g., 301 for permanent redirect
[21:12:55] <Pretorian> Can someone investigate how this can be actually be done with current SF projects? 
[21:13:13] <Pretorian> E.g. testing with a temporary redirect.
[21:13:38] <Crise> I can check right now
[21:14:25] <cologic> https://stackoverflow.com/questions/139 ... -temporary is a reasonable description of the differences between the two main HTTP response-code based options.
[21:14:31] <Pretorian> How do we move forward with your other questions, Crise?
[21:14:56] <Pretorian> This feels mostly like a Crise/cologic issue TBH.
[21:15:22] <Crise> well I will have to make some code changes first... to select the "document root" based on the subdomain used to access the site
[21:16:06] <Crise> then it is about setting up submodules in git and making sure pushes to submodules trigger an update on ovh server checkout of the site
[21:16:26] <Crise> the adding subdomain to the csr can not be automated I think
[21:16:39] <Crise> serving the challenge responses can use pattern matching
[21:16:59] <Crise> in nginx conf (unless the challenges need to be regenerated?)
[21:17:07] <cologic> They don't, no.
[21:17:55] <cologic> Whatever needs to be regenerated is done by the acme-tiny script, which places files in that challenge-response directory.
[21:19:15] <Crise> re sf redirecting, here is how it can be done:
# Re-route the SF default VHOSTs
RewriteCond %{HTTP_HOST} ^apexdc\.(sourceforge|sf)\.net [NC]
RewriteRule (.*) http://www.apexdc.net/$1 [R=301]

[21:20:18] <Crise> you may also need:
RewriteEngine on
RewriteBase /
[21:21:27] <Pretorian> I don't want to do said changes, in fear of breaking stuff, I'd suggest that cologic (or I can give Crise the necessary rights) will do said changes.
[21:21:54] <Pretorian> All right, so this is firstly something Crise is looking into, I guess.
[21:22:03] <Crise> don't do it yet... the web repos are not set up as per above
[21:22:04] <Pretorian> With regards to Git/OVh.
[21:22:09] <Pretorian> Oh, no, certainly.
[21:22:24] <Pretorian> I just mean once everything else is in palce.
[21:22:27] <Pretorian> place*
[21:23:12] <Pretorian> cologic is most likely the best person to aid you, Crise.
[21:23:31] <cologic> Happy to help on this, yes.
[21:23:40] <Pretorian> Great, let's move on.
[21:23:45] <Pretorian> Pretorian-1) NMDC URI scheme
[21:23:49] <Pretorian> The NMDC URI scheme <http://nmdc.sourceforge.net/Versions/nm ... me-0.5.txt> hasn't been updated for over a year, and I haven't submitted it to the appropriate listing for comments. My intention is to get this done before the end of the year. I would like;
a) cologic to review the document once more. I know you've done this already, but maybe we've missed something that time has made clearer.
b) someone (likely poy?) to review the document and make sure that we largely support it in at least DC++, and preferably make sure it supports all of the functionality as specified. 
c) someone (likely Crise?) to review the security of the document (cologic can do this as well, but I know he has done this already several times; I want more eyes)
d) someone (likely myself) to prepare necessary software and/or examples for use of the URI (hublists being the prime example)
[21:24:28] <Pretorian> Comments/please discuss?
[21:24:33] <poy> hadn't you sent a message about this to a mailing list? what was the status?
[21:25:35] <cologic> ^^^ I know this has come up, and there were some responses, and I don't remember what would need to be done from that regard to move this forward.
[21:25:38] <Pretorian> They asked for clarifications on some sections and those things were updated but not re-sent to the list.
[21:25:48] <Pretorian> We have not sent the current version.
[21:26:10] <Pretorian> The question was also on the usefulness of the URI or how widespread it was.
[21:26:13] <poy> link to the discussions if you still have it please? :)
[21:26:47] <Pretorian> <http://www.ietf.org/mail-archive/web/ur ... 01670.html>
[21:26:53] <poy> I will read and check the details, sure.
[21:27:10] <Pretorian> <http://www.ietf.org/mail-archive/web/ur ... html#01670>
[21:27:57] <Crise> the uri is widespread in the sphere of P2P, although as time goes by less so... I can't imagine it being widespread outside of its use case though (which is why I find this a weird criticque)
[21:28:04] <Pretorian> The list is not the final comments, it's where you should have people review your request before officially filing it.
[21:28:50] <Pretorian> I want to re-post on the current uri-review list, and if there isn't any particular scathing remarks, I'd like to file it to the official registration.
[21:29:39] <Crise> the uri is historically significant though... if one can say that about any piece of P2P software that is... but DC hasn't been mainstream P2P in a long time if ever
[21:30:11] <Pretorian> Cline has a lot of good stuff, e.g. <http://www.ietf.org/mail-archive/web/ur ... 01895.html>
[21:30:23] <Pretorian> Klyne*
[21:31:11] <Pretorian> The uri-request is supposed to be the first hurdle you should pass.
[21:31:26] <Pretorian> but yes, a historical URI scheme we can most definitely pull off.
[21:31:37] <poy> read through the thread - you've had many good exchanges!
[21:31:38] <Pretorian> I'd ideally like to get a permanent non-historical one of course. ;)
[21:32:18] <Crise> is the adc scheme a thing, officially?
[21:32:36] <Pretorian> adc://example.com:port is, yess
[21:32:45] <Crise> and adcs?
[21:32:50] <Pretorian> Err, you mean with IETF?
[21:33:05] <Crise> yeah... that is what we are talking about isn't it
[21:33:16] <Pretorian> Sorry, I misinterpreted what you wrote.
[21:33:30] <Pretorian> The adc URI is *not* an official URI scheme.
[21:33:48] <Pretorian> NMDC is more widespread and I'd like to get that passed before.
[21:34:06] <Crise> figured as much, but I thought I would ask anyways
[21:34:13] <Pretorian> This also partly because the NMDC URI scheme is actually richer.
[21:34:17] <poy> for ADC it would make sense to first submit the protocol itself - as one of the first commenters suggested, the approval of a protocol pretty much guarantees related URI schemes will get in as well.
[21:34:18] <Pretorian> (As of now at least.)
[21:34:37] <Crise> poy: good point
[21:34:45] <Pretorian> The dchub URI scheme is the first fairly technical part that isn't too large.
[21:34:57] <Pretorian> Which means it decreases the chance it'll be blocked.
[21:35:30] <Crise> well dchub uri scheme will be the first official thing about NMDC ever then... and possibly last :P
[21:36:10] <Crise> considering there is not even a real specification... per se.
[21:36:17] <Pretorian> Maybe, but it deserves a historical URI scheme or historical spec .
[21:36:42] <Crise> that it does
[21:37:21] <Pretorian> Any way, I hope you can do the necessary reviews of the proposed scheme and the interaction on the uri-requests page.
[21:37:37] <Crise> will definitely read through it later
[21:37:47] <Pretorian> ("Looks good" is a fine review response. :) )
[21:37:48] <cologic> I will look through it again as well.
[21:37:52] <Pretorian> Great.
[21:38:08] <Pretorian> All right, that's all items so far.
[21:38:10] <Pretorian> Anything else?
[21:38:16] <cologic> I have nothing else.
[21:39:05] <poy> good discussion - nothing more from me at the moment.
[21:39:28] <Pretorian> o
[21:39:29] <Pretorian> ok
[21:39:33] <Pretorian> <writing items for next meeting>
[21:40:20] <Crise> well... aside from having cologic check that the challenge responses are working, by the next meeting I have none... so please add that to the list of items for next meeting
[21:41:25] <cologic> Yeah, checking challenge responses is something I'll do for next meeting.

...

[21:41:41] <Pretorian> 1) Write additional HTTPS article. (cologic)
2) E-mail to EFF/GNU about license for the website (Pretorian)
3) Finalize donators list (Pretorian)
4) Migrate ASCIIDocs to Markdown (Pretorian)
5) Challenge-response of webpages (cologic)
6) Prepare DCNF web pages for affiliated projects (Crise)
7) Review NMDC URI scheme (Pretorian, cologic, Crise, poy)
8) Propose inclusion of affiliated projects (poy)

[21:43:21] <Pretorian> Anything I missed?
[21:43:34] <Crise> no
[21:43:45] <Pretorian> All right, that concludes this meeting. Thank you all.
[21:43:47] <Pretorian> <end>