[2017-02-05 20:00] Welcome to DCNF monthly meeting, it is 2017-02-05. [2017-02-05 20:01] For simplicity sake, I will be the chairman and Crise has agreed to act as secretary. [2017-02-05 20:01] What we do need is a head count, so just state your names. [2017-02-05 20:01] Pretorian [2017-02-05 20:01] cologic [2017-02-05 20:01] Crise [2017-02-05 20:01] All right [2017-02-05 20:01] There's a few items from the last meeting; [2017-02-05 20:02] 1) Migrate ASCIIDocs to Markdown (Pretorian) 2) Update DCNF web pages for affiliated projects (Pretorian, Crise) 3) Propose inclusion of affiliated projects (poy) 4) Setting up new affiliate project for information on DC projects (Crise) [2017-02-05 20:02] Item 1) Migration. [2017-02-05 20:02] In progress, I guess. [2017-02-05 20:02] Crise you'll review the generated documents and see if they're OK? [2017-02-05 20:02] yeah [2017-02-05 20:02] If they are I can generate it for all documentation we have. [2017-02-05 20:03] may need some manual adjustments but so far it is something we should be able to work with [2017-02-05 20:03] Ah, great. [2017-02-05 20:03] Yeah, obviously a total automatic conversion is seldom 100%. [2017-02-05 20:03] We can continue the specifics after the meeting. [2017-02-05 20:04] ok [2017-02-05 20:04] Let me know what exactly more I need to do for the files. [2017-02-05 20:04] Next item, [2017-02-05 20:04] 2) Update DCNF web pages for affiliated projects (Pretorian, Crise) [2017-02-05 20:04] I haven't done anything regarding this, Crise? [2017-02-05 20:05] What steps should we take to address this? [2017-02-05 20:05] I have not done this either, I'll set up the subdomain with a placeholder after the meeting [2017-02-05 20:06] ie. like adc.dcbase.org [2017-02-05 20:06] Great. [2017-02-05 20:06] After the site's fully converted then we need to move adc.sf.net to point to adc.dcbase.org. [2017-02-05 20:06] But that's something that is done at SourceForge I think. [2017-02-05 20:07] I don't know if you have access to those admin locations, but I can do those changes. [2017-02-05 20:07] yes, the site itself doesn't have that much content aside from the documents pending conversion [2017-02-05 20:07] I don't recall as far as my access goes [2017-02-05 20:07] Right, both the ADC and NMDC project is really sparse. [2017-02-05 20:08] As it's mostly a document pool. [2017-02-05 20:09] I think once the documents are updated then the rest follows swiftly. [2017-02-05 20:09] Got anything else to add? Otherwise we can move on. [2017-02-05 20:10] (it is not my intention to rush the meeting, let me know if I'm too quick.) [2017-02-05 20:10] I don't, at least. [2017-02-05 20:10] All right, let's move on. [2017-02-05 20:11] 3) Affiliated projects, poy's item, so I guess we'll have to keep that until the next meeting [2017-02-05 20:11] Next item; [2017-02-05 20:11] 4) Setting up new affiliate project for information on DC projects (Crise) [2017-02-05 20:11] Anything done here? [2017-02-05 20:11] It feels like we should make a plan for what can and should be done here. [2017-02-05 20:12] If the only thing we're going to do is simply to copy wikipedia and/or other resources, then maybe that's not very difficult... [2017-02-05 20:13] well this is mostly the same thing as with the two other affiliate project as far as technical setup is concerned [2017-02-05 20:14] So it's mostly the content we're effectively missing (or haven [2017-02-05 20:14] haven't compiled)? [2017-02-05 20:14] as for content, well... we probably have to start off with taking content from existing resources where appropriate and possible, however, eventually it would be nice if client maintaners took at least enough interest to keep info about their own clients updated [2017-02-05 20:14] Right -- and for that, would it be possible to have a bot that automatically pulls that data? [2017-02-05 20:15] Similarly as the Twitterbot is currently doing. [2017-02-05 20:15] in theory yes, building a parser for an rss feed or version.xml type file is not that difficult [2017-02-05 20:15] So people don't have to manually go an update the version on the affiliated page. [2017-02-05 20:15] It'd also mean the page isn't absolete immediately when person X stops updating it. [2017-02-05 20:16] it would be a good approach yes [2017-02-05 20:17] There should be one page (affiliated project) that lists all other affiliated projects, and there should be one page (affiliated project) that list all software etc. [2017-02-05 20:17] So maybe "affiliated project" page isn't accurate but rather "DC projects". [2017-02-05 20:18] yeah, like I mentioned in the annul meeting the main point of having this as an affiliate project is to easily control who can update stuff and who can't [2017-02-05 20:18] *annual [2017-02-05 20:19] Sure, but I think it's important that we automate as much as possible -- in terms of software versions etc. [2017-02-05 20:20] yeah, that kind of automation is possible... provided the source of the information is universal enough [2017-02-05 20:20] Yup. [2017-02-05 20:20] (ie. if I have to code a separate parser for each projects info, it kind of defeats the point) [2017-02-05 20:20] So we need to a) build/find such a bot and b) make a webpage that can appropriately display it. [2017-02-05 20:21] I guess the intial step is to just attempt to find such a bot. [2017-02-05 20:21] There's probably loads out there. [2017-02-05 20:21] I think it's like 5 lines of code in Python. [2017-02-05 20:21] twig is quite powerful, as long as we have the data in say json format it is easy to display with twig [2017-02-05 20:22] so the problem is aggregating all the data into a source that the site can use [2017-02-05 20:23] cologic: Sorry for singling you out, but can you have a look into such a both (Python) that can possibly generate such JSON content? [2017-02-05 20:23] It's you and poy that are Python experts™. [2017-02-05 20:24] Sure. [2017-02-05 20:24] as long as the format isn't difficult to parse, other formats are fine as well... json is just the simplest example because the site already does that [2017-02-05 20:24] I guess as long as we can confidently grab the data then the output is just deciding on some format (in this can JSON if the site can read it). [2017-02-05 20:25] it can, the menu is defined as a json file [2017-02-05 20:25] The Twitter bot that is set up for is spamming such links so it's defintely possible to do. [2017-02-05 20:26] Who runs that bot? [2017-02-05 20:26] At the moment, no one. It used to be but it's closed down. [2017-02-05 20:26] I haven't set up any alternative. [2017-02-05 20:26] Ah, that's why it stops at 0.862. [2017-02-05 20:27] Yeha [2017-02-05 20:27] yeah* [2017-02-05 20:28] Most feeds it was subscribing to are published on Reddit, I think. [2017-02-05 20:28] DC is on reddit? [2017-02-05 20:28] [2017-02-05 20:28] Not much activity but still. [2017-02-05 20:29] [2017-02-05 20:29] All right, let's move on. [2017-02-05 20:29] That's all items from the previous meeting. [2017-02-05 20:29] Does anyone have any additional items? [2017-02-05 20:30] Pretorian-1) Automatic management (pooling) of hublists [2017-02-05 20:30] [2017-02-05 20:30] I don't have any additional items. [2017-02-05 20:31] (nothing in particular, though anything hublist related is a topic I am interested in) [2017-02-05 20:31] All right, I'll dive into my item. [2017-02-05 20:31] It's mainly focused on the legality of having a hublist management service on the main website. [2017-02-05 20:31] Basically, all hublists that are included in clients nowadays are hard coded. [2017-02-05 20:31] So to update the list one is required to update the software. [2017-02-05 20:32] However, it would be technically possible for the client to go to e.g. dcbase.org/hublists and gather a list of hublists. [2017-02-05 20:32] well dcbase,org can easily host an xml file or another format a client can digest [2017-02-05 20:33] This is tied to having a hublist on dcbase.org itself, too, but I'm not there yet (plus there's lots of technical challenges of running a hublist ourselves). [2017-02-05 20:33] But the issue I see is a legal one. [2017-02-05 20:33] Can we host such an XML without falling into the "badversion" technicality that we had with DC++? [2017-02-05 20:34] If we can automatically influence clients which hublists they can access, then we can potentially influence good or bad hubs. [2017-02-05 20:34] it is not a kill switch though, and as long as it ammeds the clients own selection rather than replacing it can we do harm with such a file [2017-02-05 20:34] Which makes us potentially liable regarding copyright infringement (a la EFF). [2017-02-05 20:34] I'm not sure that's avoidable, but it's less severe, as Crise notes. [2017-02-05 20:34] But, is it worse than right now? Where the client has them hard-coded. [2017-02-05 20:35] (ie. does anyone have any interest in controlling that file, and if they did what would they seek to achieve with it) [2017-02-05 20:35] So, should there simply be a hublist project that (at the moment) would serve such an list? [2017-02-05 20:35] Then it's just a matter of getting clients to use it of course, but that's simple. [2017-02-05 20:36] I'd prefer a way for client developers to use their own hublist file. [2017-02-05 20:36] In case e.g. DC++ and AirDC++ don't want the same hublists. [2017-02-05 20:36] we can make it a "protocol extension" / recommendation through ADC at least [2017-02-05 20:37] as well as provide a file of our own that conforms to that documentation [2017-02-05 20:37] if people do want to use it [2017-02-05 20:37] You mean a hublist file format? [2017-02-05 20:37] I'm just talking about a file pointing to other hublist files. [2017-02-05 20:38] yes, but a format for that file... specifying how to implement it [2017-02-05 20:38] Not sure if that's necessary for "ADC" per se, though. [2017-02-05 20:38] But yeah, definitely there should be documentation for it. [2017-02-05 20:39] i mean version.xml is already more or less a de facto standard as a starting point... this would just be an official version of that but for hublists [2017-02-05 20:39] Yeah. [2017-02-05 20:39] where you want to affiliate such a document with isn't really that important [2017-02-05 20:39] It's not obvious to me, based on my understanding of the EFF's guidelines, that this would be more dangerous or risky than what exists now. [2017-02-05 20:40] what are the risks though? [2017-02-05 20:40] or rather are the risks realistic [2017-02-05 20:40] cologic: Well, my initial concern is whether we can influence released software. [2017-02-05 20:40] you already are [2017-02-05 20:40] ^^^^ [2017-02-05 20:41] How are we influencing already released software? We can't push data out. [2017-02-05 20:41] see version.xml blacklist items in dcpp... it has parsing code for that right? [2017-02-05 20:41] And, as Crise has suggested, it can only amend, not remove, on the client side, which removes any obvios novel risks. [2017-02-05 20:41] Huh? No, the blacklist is removed? [2017-02-05 20:41] I removed that blacklist years ago. [2017-02-05 20:41] Including the parsing code. [2017-02-05 20:41] cologic: right, if we just append the data, then we should be good [2017-02-05 20:41] the hub dns blacklist? [2017-02-05 20:41] Oh, not that one. [2017-02-05 20:42] it has parsing code from the version.xml correct? [2017-02-05 20:42] I believe so, yes. [2017-02-05 20:42] that is already influencing released software then [2017-02-05 20:42] Perhaps the clients can allow a button for "promote as normal hublist/don't remove this in the future". [2017-02-05 20:42] even if the xml has no items tha differ from the hard coded ones afaik [2017-02-05 20:42] Pretorian: sounds reasonable [2017-02-05 20:43] Hm, the DNS blacklist, can that be updated through version.xml? [2017-02-05 20:43] I believe so [2017-02-05 20:43] Hm, damn. [2017-02-05 20:44] Any way, so, we need a different affiliated project - a hublist project [2017-02-05 20:44] although that too is a soft blacklist, because it doesn't actually block functionality just asks the user [2017-02-05 20:45] I guess... but hopefully we have other stuff for it besides one xml file [2017-02-05 20:45] Its purpose (my proposal) is to do the following; 1) Provide an XML pointing to hublists 2) Provide actual hublists 3) Provide/point to source code/documentation regarding hublist software etc 4) Strive to build a distributed hublist (a la FEED etc). [2017-02-05 20:45] sounds good [2017-02-05 20:45] Agree, seems reasonable/useful. [2017-02-05 20:46] in my opinion too, the organization should aim to provide people the tools to create hublists... [2017-02-05 20:46] Yeah, definitely. [2017-02-05 20:46] Crise, can you also make a hublist.dcbase.org project? [2017-02-05 20:46] sure, I will just add it to the list :P [2017-02-05 20:46] hehe sorry :P [2017-02-05 20:47] I'll draft up such a list and poke poy regarding the feature. [2017-02-05 20:47] So it'll at least be in one client. [2017-02-05 20:48] I'm done with this item at least. Anything else to add? [2017-02-05 20:49] not really, I mean there is a lot to discuss when it comes to hublists and the dependency on them (as well as lack of open hublist hosting solutions) but we should start small [2017-02-05 20:49] Yep. [2017-02-05 20:49] I don't have anything else to add, no. [2017-02-05 20:49] All right, does anyone have any additional items that they thought of? [2017-02-05 20:50] I have no additional items. [2017-02-05 20:50] not from me [2017-02-05 20:50] Next meeting items; [2017-02-05 20:50] Migrate ASCIIDocs to Markdown (Pretorian) Update DCNF web pages for affiliated projects (Pretorian, Crise) Propose inclusion of affiliated projects (poy) Setting up new affiliate project for information on DC projects (Crise, cologic, Pretorian) Hublist project (Crise, Pretorian) [2017-02-05 20:51] If there's nothing further, that concludes this meeting. Thank you all.