[20:04:02] Welcome to DCNF monthly meeting, it is 2016-05-01. [20:04:22] oFor simplicity sake, I will be the chairman and Crise has agreed to act as secretary. [20:04:33] What we do need is a head count, so just state your names. [20:04:35] Pretorian [20:04:39] cologic [20:04:54] Crise (yay on time for roll call :P) [20:05:09] klondike? [20:05:21] (anyone can join) [20:05:36] Oh well, let's continue. [20:05:39] Pretorian: yes [20:05:44] Klondike [20:05:48] There's a few items from the last meeting; * Research potential avenues for acquriing legal information (all) * Move files (non HTML) to the Gitlab site. (Crise) * Write HTTPS article. (cologic) * Tax papers - fill out and see if it's possible to merge with translation. (Pretorian) * Internetfonden - people should think of the suggestions. (all) * Research GSoC? (Pretorian/Crise/all) * Approach developers on what they want from DCNF (all) * Think of ways of providing infrastructure to plugins etc. (all) [20:05:58] We'll deal with additional things after these. [20:06:10] Item 1: * Research potential avenues for acquriing legal information [20:06:21] I haven't really done this, anyone else? [20:06:38] Not much "to do here", I guess, unless people have suggestions. [20:07:05] Pretorian: what is acquiring legal information? [20:07:23] Information about legal matters/questions that pertains to the organization. [20:07:30] As well as DC as a whole. [20:07:43] I have not, either. My basic suspicion is that there's no free and effective way to do this, since as we've discovered the EFF/etc focus on different priorities. [20:08:04] Ohh [20:08:17] lawyers like getting paid.... [20:08:58] Crise: indeed. There doesn't seem to be a good reason to expect this gratis, either, just in general. I wouldn't expect the DCNF to be a high-priority case in this regard. [20:09:22] Everyone keep their eyes open, I don't forsee anything changing in this area unless people find a proper channel. [20:09:38] but really the most important question that we need an answer to is whether various safe haven rules apply to organization such as this... and if yes which country's [20:10:16] The rules in Sweden (and EU, I guess) should apply completely. [20:10:39] However, I know that the US is annoying when it comes to software and contributions made by americans (export rules etc). [20:11:00] Does that apply to anything except cryptography? [20:11:06] Yes, everything. [20:11:14] Even a literal screw. [20:11:47] The US does take a rather expansive position on its global jurisdiction. [20:11:57] E.g., americans are barred from making any software changes to our (my company) software code; the US "has a legal right to it after they do". [20:12:43] (They can look at code but not contribute.) [20:13:03] Oh well, let's continue. It's unlikely we will make any headway regarding legal issues at the moment. [20:13:14] Item 2: Move files (non HTML) to the Gitlab site. (Crise) [20:13:26] Crise: you have adressed this somehwat, I reckon? [20:14:09] In short, I will dump the meeting logs + resources, such as court documents we mirror, to a repository on gitlab (will link in a moment) [20:14:19] Great. [20:14:32] Do we have any size limitations? [20:14:35] On files. [20:14:55] I'm thinking of whether we can host software files or other interesting DC files that may be "large". [20:15:15] well the usual caveat of git when it comes to large files does apply, but for written documents and whitepapers PDF's etc. should be fine [20:15:22] Perhaps not the most ideal place to but them, I understand, I'm just trying to understand what potential limitations we might have. [20:15:37] Pretorian: as a piece of advice avoid large blobs on git :P [20:15:48] Is file size an issue with Git per se or Gitlab? [20:15:53] Does it support git-annex or similar? I don't totally understand how they work, or whether they work at all with arbitrary remote git servers. [20:16:04] Gitlab does support git-annex [20:16:17] That should ameliorate large blob issues. [20:16:21] What is Git-annex? [20:16:22] Pretorian: git per se. [20:16:56] also, gitlab imposes a 10gb uppoer limit on any project repository [20:17:13] A tool which (and other people probably understand it better than me) creates a kind of secondary git storage mechanism specifically for large files which aren't usefully diff'able. [20:18:10] https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/ [20:18:28] my rule of thumb when it comes to git is, if you can diff it... it's fine, if not... unless it is less than 1mb binary file or pdf it goes outside the normal git repo [20:18:58] Crise: You might have more to present, and I apologize if I'm getting ahead of myself, just let me know. Do we need to modify the HTML files as well (to point to new files) or will you set up some script that goes through the directories? [20:19:05] From one of the Gitlab comments in response to the article though: "Hi John, thanks for asking. We understand the desire to have this in CE but this is one of the few features that is requested by a lot of large organizations and not many small ones. Of course we understand that smaller organizations and individuals like you would like it too. But there has to be extra value in the enterprise edition. We have to make hard decisions about what is EE only and we currently have no plans to port this to CE. As a workaround you can setup a separate git-annex server." [20:20:18] However -- for smallish PDFs, etc, it shouldn't matter too much, if Gitlab behaves like git in general. [20:20:31] I elluded to this a bit before the meeting, but the idea is to setup a front controller on the server that combines a single page from three parts, header, body and the footer... the advantage here is that we can add intermediate parsers such as markdown onto the stack [20:21:45] I tried to get more done today, but at the same time... I wanted to avoid a fullblown MVC setup, because it is overkill and third party frameworks involve maintenance [20:22:46] Do you need help with anything? (My experience with web development is mostly HTML.) [20:23:51] It seems like klondike might be of some (at least discussion wise) assistance? [20:23:57] so yeah, the html files as they are now will need to be adapted eventually, however, not before the I pull the repository to the server... no help needed really at this point but once the setup is complete and documented I might need some help in content migration, as for the org documents, those will probably live under their own subdomain [20:24:12] ie. resources.dcbase.org [20:24:46] That's fine I guess. I had no real thought behind the directory management, beyond that it was no "extra" stuff to set up. [20:25:24] Pretorian: all I can say is that header->content->footer in PHP is easy :P [20:25:44] I will write some documentation once I finish implementation, if you hate what I am offering at that point you can feel free to propose alternatives [20:25:50] Don't make it much more complicated and Crise will not say sadly when referring to PHP :P [20:26:04] Crise: Sounds fair enough. [20:26:17] Crise: worst I could do is using my pentest tools, so no worries [20:26:25] https://gitlab.com/groups/dcnf [20:26:47] both the repositories should be public, the resources one I haven't pushed to yet [20:27:38] though I doubt what is there in the dcbase.org repo will tell much to anyone, except maybe klondike if he happens to be curious enough to look [20:28:39] If people have suggestions for the type of resource they wish the site should provide/have, feel free to suggest. [20:28:40] The only semi-recurring issue I can think of here is people who put some authentication token for some service in a repository without thinking. [20:29:14] When it comes to content production, I will only say that if you have ever worked with some intermediate "templating" engine that kind of experience will probably be useful [20:29:23] Not that it's the case right now, but every few months someone does a Github or Google search for a useful string format and discovers thousands of respoitories with that. [20:29:31] *repositories [20:30:09] cologic: let me help username = admin password = 1234 [20:30:24] there won't be any authentication tokens at all, as my aim is to not use databse... the git version history and merges will replace what I would normally do with databses in a more traditional system [20:32:22] Ok, well, let us know when/if you need help. [20:32:48] Let's move on unless people have more to discuss regarding this. [20:33:23] Item 3: Write HTTPS article. (cologic) [20:33:38] cologic: Status check? [20:33:55] In progress. Not adequately edited for my taste. I'll have it posted in the next few days. [20:34:04] Great. [20:34:10] cologic: I can help you with edition if you want [20:34:34] klondike: ah, especially since you're also familiar with crypto, etc, that would be helpful, yes. [20:34:56] It's about using Let's Encrypt with some variations which aren't so commonly discussed. [20:35:28] Sounds like something I could do then, count me on [20:35:57] All right, let's continue. [20:36:03] this is but an anecdote, but I am looking forward to this article (need to move away from paid ssl certificates if possible) [20:36:22] Item 4: Tax papers - fill out and see if it's possible to merge with translation. (Pretorian) [20:36:58] Pretorian: skatteverket being the usual PITA? [20:37:02] In progress as well, I will be doing my personal taxes today and I'll attempt to find an appropriate merge for the DCNF documentation while I'm at it. [20:37:16] Not really, the tax form is pretty straight forward. [20:37:29] I just want to have it translated/annotated for the non-Swedish readers. [20:37:53] Since DCNF is tax exempt, there's not much to fill it beyond contributions/member fees. [20:38:02] (And the single expenditure. [20:38:21] Let's move on, I guess. [20:38:28] Item 5: Internetfonden - people should think of the suggestions. (all) [20:39:08] I don't really have any immediate "I want to do this" projects. [20:39:23] Hang on, I'll make a short list of the proposed so far: [20:40:13] * Build mobile app * Build browser-addons with DC backbone * Build architecture for e.g. game publishers to transfer files (peer-to-peer) based on DC backbone (similar to how World Of Warcraft uses Bittorrent to transfer updates etc). * Web app (different than browser addon or mobile app; accessible in some different circumstances) * ADC as exemplar of semi-decentralized, encrypted infrastructure for chat which doesn't rely on single points of failure and for which (Slack, Hipchat, etc) there's evident demand for the idea in general. * Put a decentralized hub listing mechanism into place * ADC bridges with IRC / Slack / etc * Bridge Bittorrent and DC applications via magnet links [20:40:34] From the last meeting. [20:41:12] The one thing that's come up a couple of times, whilst I've tried to keep this in mind, is how it'd be handy sometimes to have almost a web UI or other frontend/backend separation for a chat use of DC. After using Slack and HipChat in various situations, there are several relatively-easy-to-replicate features they have UI-wise which aren't so much a protocol thing as a kind of integration. Being able to log on and have history visible in a smoother way, etc. This is an elaboration of my Web app suggestion from before in some ways. [20:41:48] cologic: we are working on it (for realz) [20:42:03] It's not all that technically hard, but I think they show how much value there is in packaging basically-IRC nicely. [20:42:11] Removing the friction and pain points. [20:42:19] klondike: nice. [20:42:53] cologic: at Euskal Encounter we need to integrate DC with the web based intranet so hopefully we'll get a DC client (using websockets) out of this [20:43:27] There is also work being carried to set the websocket server in front of an uhub server by marcan [20:43:31] please do, because then I don't have to do it (in PHP :P) [20:43:32] klondike: You're not synching this with the AirDC++ implmentation? [20:43:40] Even chat-only, which websockets should be capable of, would be nice. [20:45:00] Pretorian: no, my objective is being able to have the full client on the browser [20:45:10] Fair enough. [20:45:13] Not sure what AirDC has in mind though [20:46:31] All right, let's continue, we won't make any more headway regarding Internetfonden.se. If people have suggestions that they will warrant such a project, feel free to suggest it. [20:46:47] Item 6: Research GSoC? [20:46:55] (Google Summer of Code) [20:46:55] re AirDC implementation, their web client is intended for local use by single user [20:47:07] I haven't done this, don't know about anyone else. [20:47:44] Pretorian: it isn't too hard, first step is getting the poject approved [20:47:50] (on GSOC I mean) [20:48:03] Sure, but need a project first. [20:48:17] I haven't looked into at all the requirements etc. [20:48:27] GSoC tends to focus on specific software projects. [20:48:35] There might be things, such as that we need to operate in the US. [20:48:40] So, not general R&D on how to do thing X. [20:48:58] But, "we know feature X would be nice to have and roughly how to do it". [20:49:53] Pretorian: think of for example adding X on DC++ (or AirDC or whatevs) [20:50:27] First step is still getting the project accepted though there is some deadlines for these things (I doubt we'll make it for this year) [20:52:32] People should read through the rules and see if DCNF happen to break any of them. [20:52:38] I'll attempt to do so tomorrow. [20:52:47] Let's continue. [20:52:52] Item 7: Approach developers on what they want from DCNF (all) [20:52:59] (I haven't done this at least.) [20:53:03] Anyone else? [20:53:38] I haven't done this either, apart from asking poy in the previous meeting... but he basically wants a mini SF [20:54:44] * klondike is happy with a place to keep standards+ protocol discussions [20:55:41] I'm looking for two main things: (1) a legal entity which has control over resources to avoid certain personal drama fallout from the past; and (2) a 'mini SF' as poy-via-Crise suggests. [20:56:32] I've never been totally clear on the actual aspirations of these 'incorporating project X', etc, ideas, for example. [20:57:11] ADC/NMDC protocol projects are such projects. [20:57:40] Ah, okay, that's actually really helpful for me to understand the goals. I see the value more clearly now. [20:58:29] I think it's important to distinguish projects that are owned/operated by/supported by DCNF, and projects where DCNF provide some form of resource (e.g. a source code repository). [20:58:49] The former is ADC/NMDC, and the latter would be if e.g. DC++ were to host its source code on DCNF's server. [20:58:54] I guess I'd see it as an interoperability resource, then. [20:59:25] It seems important for DCNF to own projects that involve compatibility (such as protocol, but potentially beyond that) between different client and hub implementations. [20:59:29] The "mini SF" part would essentially be that DCNF would provide all necessary hosting as done by "SF" (or similar). [20:59:39] Yeah [20:59:58] I view the repositories, etc are a corollary of that, largely, a dependency. [21:00:07] Necessary, but not the basic motivating factor. [21:00:23] I'd say e.g. test applications/protocol demonstrators to fall in under DCNF's own projects. [21:00:34] Those are other good examples, I'd agree. [21:00:40] DCNF shouldn't provide user-software per se. [21:00:56] If it does, it'll just mean we end up in a "DC++ is the main client" type of scenario. [21:01:02] Which is bad. [21:01:21] I'd go for protocols, compliance tools, reference implementations [21:02:19] having an actual reference implementation would be cool [21:02:42] since poy is adamant that DC++ is not such an implementation (and for good reason) [21:02:56] I've compiled a few of such projects/suggestions at [21:03:11] A reference implementation should ideally just test the protocol(s). [21:03:16] Indeed -- one without a GUI, a lot of the ancillary user-friendly aspects, etc. [21:03:33] But also which allows the kind of automation one needs to test compliance. [21:05:30] cologic: How can DCNF ameliorate your (1)? [21:06:08] It already does, basically, if you're referring to the legal entity. By continuing to exist, it satisfies that goal. [21:06:15] Fair enough. [21:06:48] Addressing password management is going to be hard, I reckon anyway. [21:07:32] Yeah, though largely for social reasons rather than anything technical. It's a paradigmatic case of creating the policy being hard but enforcement of any specific policy being easy. [21:07:42] Pretorian: clear text passwords, be open about it :P [21:07:51] It's all you need [21:08:58] The board should ideally generate new passwords when they take over after the yearly meeting. [21:09:27] That's as reasonable as anything. One can form more complicated policies, but they're probably not worth it. [21:09:45] Ohh you meant handling dcbase passwords xD [21:09:46] (I don't actually need to be in the board, mind you, I think.) [21:10:08] I thought it needed a Swede? I forget the exact constraints. [21:10:17] Not now, I think. [21:10:23] It was required when forming. [21:10:42] Well that's a blatant loophole in Swedish corporate law. [21:10:44] Contraints still in place is the 50% rule. [21:10:56] Why? [21:11:36] Why ever require a Swede's involvement if it only has to exist for the first moments of an organization, before a new board can reform without a Swede? I don't see what it gains. [21:12:00] cologic: Perhaps that says more about your country than mine? :P [21:12:15] Oh well, we're going off track. [21:12:22] Let's continue with the next item [21:12:25] (Will stop tangent here, yes.) [21:12:31] Item 8: Think of ways of providing infrastructure to plugins etc. (all) [21:12:43] (I haven't thought of anything.) [21:12:47] Anyone else? [21:13:01] That's what Crise is setting up to some degree, no? [21:13:48] Not now, no. [21:13:52] But I guess, down the line? [21:15:00] Ah, perhaps. I didn't mean to push Crise to do anything specific here but misunderstood the scope of his current project. [21:15:14] It seems like it's at least a useful precondition. [21:16:05] depends what you have in mind for infrastructure [21:17:18] if it needs a relational database, then I am staying out of that can of worms for now... mainly because I want a slim layer that can be largely left unmaintained once proven working [21:18:34] Let's start there and build on it. [21:19:06] I can help with the relational DB thing xD [21:20:30] Unless people have additional things to add to it, let's continue. [21:20:39] That was all of the items from the previous meeting. [21:20:51] Does anyone have any additional items they want to bring up? [21:21:06] I do not, no. [21:21:57] I do [21:22:11] Shoot [21:22:14] I'd like input on the ADC over websockets propossal [21:22:42] Particularly before we set on making the client+hub needed for it and make it stone written [21:23:08] Is this a different protocol or a different implementation of ADC or ADCS as already exists? [21:24:02] cologic: good old ADC, just different transport [21:24:10] The main issue is websockets are message based [21:24:35] (At least that was my idea unless anybody thinks a different protocol makes more sense) [21:24:58] In a UDP sense, or? I'm unfamiliar with WebSockets' details. [21:25:37] Or, I guess, "reliable UDP". [21:26:02] cologic: reliable UDP yes [21:27:20] The idea I had there is send usual \n terminated messages, you can send one or more per message but not partial ones [21:27:39] Not sure if that can byte us afterwards though [21:27:58] I'd agree, at first sight. Obviously, I've not thought about this for more than seconds. [21:28:39] Some caveats -- ADCS leaks information this way. [21:28:50] Just traffic-analysis-wise. [21:29:06] I can give it a month or so though [21:29:17] cologic: I'd *love* to do/see a traffic analysis of the protocols. [21:30:31] klondike: one could imagine increasingly sophisticated countermeasures, but for the interactive portions, there's the usual latency/bandwidth efficiency tradeoff of these sorts of protocols. No Free Lunch, etc. [21:31:17] And, I'm not sure that needs to be baked into the protocol-per-se regardless. [21:32:06] Hum [21:32:10] Pretorian: it's come up before, and I think we never really had adequate data for this. Simulations, perhaps, but it's nice to have grounded, empirical data too. [21:32:36] Or, is SUDP implemented yet? That seems like it would naturally fit in. [21:32:44] (Implemented by, well, any client.) [21:32:46] Personally I think disclosing that ADC is running over TLS is not an issue [21:32:52] A Monte Carlo simulation could still provide quite a lot of information. [21:33:16] Uhm, I need to leave shortly. [21:33:23] Sure, and we have enough source data (hub size distribution, nick length distribution, etc) to do something useful. [21:33:25] But if that is an issue then sure, we can just fragment packets and let that be that way :) [21:34:00] I'd say the bigger risk is probably allowing fragmented packets, because reconstructing them has proven repeatedly surprisingly vulnerable. [21:34:26] klondike: Do you need an action from DCNF until the next meeting? I mean, you can of course continue to discuss this after the meeting. [21:34:28] I'm thinking more along the lines of creating a kind of padding, or bundling to specific minimum packet sizes. [21:34:37] I just don't want us to get stuck on this for the purpose of the meeting. [21:34:48] Pretorian: no, we (euskal guys) can wait a month more [21:34:55] Ok. [21:34:55] But as before, this is all half-baked from my end at the moment, so shouldn't be taken too seriously. [21:35:05] Okay, I'll stop here then and we can continue later. [21:35:14] Unless people have additional things for the DCNF meeting? [21:35:30] cologic/klondike: Feel free to continue to discuss, but I'd like to "close" the meeting. [21:35:43] Actions for the next meeting; [21:35:45] * Move files (non HTML) to the Gitlab site. (Crise) * Write HTTPS article. (cologic/klondike) * Tax papers - fill out and see if it's possible to merge with translation. (Pretorian) * Research GSoC. (Pretorian) [21:36:04] All right, that concludes this meeting. Thank you all.