Code: Select all
hl | indolering: Alright. Can I record your vote as abstain then?
indolering | hl: sure.
No strong preference: indolering, Domob
Now against: phelix (I infer)
Yet to express a preference: cassini
Code: Select all
hl | indolering: Alright. Can I record your vote as abstain then?
indolering | hl: sure.
I agree that deterministic builds are important, but what is really stopping us from simply running the source through a Python interpreter? I thought that's how it is supposed to be done anyway. With respect to a reproducible Python interpreter: What's the point if you can simply use the one bundled and signed by a major distro? You have to trust "some" component of your OS anyway.biolizard89 wrote:Reproducible builds are very important, and I don't think Joseph or I want the project to be completely dependent something that Tor devs were unable to do with several orders of magnitude more funding.
At this moment reproducible builds are of secondary priority. What is important is that we get out a working product.biolizard89 wrote: Reproducible builds are very important, and I don't think Joseph or I want the project to be completely dependent something that Tor devs were unable to do with several orders of magnitude more funding.
domain-names.md is not the benchmark. Is ncdns ready to be deployed as a product (on Windows)?hla wrote:ncdns (which provides DNS resolution) works today. It is the only currently available implementation of domain-names.md, as far as I'm aware. So if we compare the completion of the two implementations, ncdns wins, unless I'm mistaken.phelix wrote:IMHO we should not discard all the work we have put into NMControl when we are just about to have a usable product. It simply does not make sense to restart now.
Well, as far as I understand the still vague question at hand it is suggested to "switch" from NMControl to something new based on ncdns.Who's suggesting we do that?phelix wrote:Why not have a competing second program? I think Go is a very interesting language but I for myself would have to dig into Go first which would take time and effort I would rather spend on other things. If you and others think they can create something better than current NMControl it's fine with me. But we should let the users decide and not force a single "official" software on them.
It does not make sense to have all developers switch from one language to another in the middle of a project either. Particularly not so as most other code and scripts are in Python, too. This will forbid some synergy effects (we are only partially using so far) and will divide the team.People can use what they like - but it doesn't make sense to divide the limited energies available between two middleware stacks within the context of the project.
Huh? At some point you will need to have a compiler for Go, too.I believe the issue pertains to creating reproducible builds of the Python interpreter itself.phelix wrote:Whereas Go might be easier to create reproducible builds it is possible to simply run the python source directly (e.g. with Bitmessage this is pretty common).
Who cares about large zones?DNSSEC is essential to allowing d/ names to securely delegate to nameservers, which is necessary for large zones.phelix wrote:DNSSEC is low priority from my current point of view, if not even a dead end: https://forum.namecoin.info/posting.php ... 70&p=15526
For TLS support it is not necessary for the browser to support anything but a (socks) proxy.Moreover, the issues with getting DNSSEC support into browsers are basically the same issues as getting Namecoin TLSA verification support into browsers. They are essentially the same problem.
Wow, not having to worry about error handling is indeed an advantage.If the fallibility of a given function is explicitly declared, callers know they need to handle any errors which it returns. Unlike Python, Go is statically typed and uses returned error values. Therefore, it can be determined from the documentation whether the function can fail, and, when writing Go, all such failures are generally handled appropriately.phelix wrote:I don't see how you could get around this in any language. It was never a problem for though.biolizard89 wrote:in Python it is difficult to know which exceptions to catch.
Yes.phelix wrote:domain-names.md is not the benchmark. Is ncdns ready to be deployed as a product (on Windows)?
I understand the proposal is to switch to ncdns, not something based on it. Of course the codebase can be evolved from its current state to provide whatever functionality is required, but ncdns is complete.phelix wrote:Well, as far as I understand the still vague question at hand it is suggested to "switch" from NMControl to something new based on ncdns.
But I think it's been carefully explained exactly why this switch makes sense.phelix wrote:It does not make sense to have all developers switch from one language to another in the middle of a project either. Particularly not so as most other code and scripts are in Python, too. This will forbid some synergy effects (we are only partially using so far) and will divide the team.
phelix wrote:Who cares about large zones?
I am assuming you are advocating MitM-based support for custom validation. This is a highly undesirable hack and certainly should not be an end aspiration. Jeremy Rand and I are both opposed to the use of MitM-based methods if at all possible.phelix wrote:For TLS support it is not necessary for the browser to support anything but a (socks) proxy.
Do you want more? Python is lacking a mature DNS library. It is very unclear to me that tightly coupling NMControl with Unbound using Unbound's python extension interface will particularly solve this issue, and it creates undesirable tight coupling. Go has a mature, widely-used DNS library on which ncdns builds.phelix wrote:As far as I see it the two main arguments for Go, reproducible builds and a DNSSEC library are void.
Not sure what your position here is. "Writing correct programs is hard, screw that"?phelix wrote:Wow, not having to worry about error handling is indeed an advantage.
Huh? It already has a name, ncdns.phelix wrote:But you are free to do your thing (btw please give it a proper name soon) and have it compete with NMControl.
I think Phelix may be talking about ncdns not having a REST interface. That said, REST is relatively straightforward to implement in Go, correct? Phelix may also be talking about the lack of identity-based functionality, which to be fair NMControl doesn't do a great job of either. My take is that the functionality that is missing from ncdns will probably be easier to implement than the functionality that's missing in NMControl. But, this is secondary to my concern about reproducible builds.hla wrote:Yes.phelix wrote:domain-names.md is not the benchmark. Is ncdns ready to be deployed as a product (on Windows)?I understand the proposal is to switch to ncdns, not something based on it. Of course the codebase can be evolved from its current state to provide whatever functionality is required, but ncdns is complete.phelix wrote:Well, as far as I understand the still vague question at hand it is suggested to "switch" from NMControl to something new based on ncdns.
I would prefer to avoid intercepting proxies where feasible. I am not certain that we can completely avoid it for all use cases, but we should definitely be trying to implement TLS without intercepting proxies. Hugo and I have been hacking around with Firefox -- things were working until Firefox 39, at which point Mozilla changed the behavior of the API we were using. I think it's possible to work around this, but not sure. If Mozilla supported TLSA records, that would make a lot of the pain just go away.hla wrote:But I think it's been carefully explained exactly why this switch makes sense.phelix wrote:It does not make sense to have all developers switch from one language to another in the middle of a project either. Particularly not so as most other code and scripts are in Python, too. This will forbid some synergy effects (we are only partially using so far) and will divide the team.phelix wrote:Who cares about large zones?
Since you clearly don't care about this use case, I would suggest you retract your proposal to ban delegation to external nameservers, and thus make Namecoin unusable for anyone who does care about this use case.I am assuming you are advocating MitM-based support for custom validation. This is a highly undesirable hack and certainly should not be an end aspiration. Jeremy Rand and I are both opposed to the use of MitM-based methods if at all possible.phelix wrote:For TLS support it is not necessary for the browser to support anything but a (socks) proxy.
Technically we could use madns with NMControl -- indeed I started on that but didn't get very far. Using ncdns is cleaner, though.hla wrote:Do you want more? Python is lacking a mature DNS library. It is very unclear to me that tightly coupling NMControl with Unbound using Unbound's python extension interface will particularly solve this issue, and it creates undesirable tight coupling. Go has a mature, widely-used DNS library on which ncdns builds.phelix wrote:As far as I see it the two main arguments for Go, reproducible builds and a DNSSEC library are void.
I would favor renaming whatever we end up with to make it more clear that (1) it's not just for DNS, i.e. identities are covered too, and (2) it's not just for Namecoin, i.e. you could use it with other naming systems if you wanted to. This kind of depends on what architecture we want to go with -- do we put everything in one program, or have lots of little programs that call common libraries? (That's an open question that can be settled separately.) Also, sugarpuff really wants it to be clear that the code works with any naming system, if he is to be involved. (I still need to talk to sugarpuff about that.... I seem to have too much to do.)hla wrote:Not sure what your position here is. "Writing correct programs is hard, screw that"?phelix wrote:Wow, not having to worry about error handling is indeed an advantage.
Huh? It already has a name, ncdns.phelix wrote:But you are free to do your thing (btw please give it a proper name soon) and have it compete with NMControl.
Interesting. I'd like to give it a try.hla wrote:Yes.phelix wrote:domain-names.md is not the benchmark. Is ncdns ready to be deployed as a product (on Windows)?
1. Install Go (1.4 or later should do fine).phelix wrote:Interesting. I'd like to give it a try.hla wrote:Yes.phelix wrote:domain-names.md is not the benchmark. Is ncdns ready to be deployed as a product (on Windows)?
Whoops, totally missed this post, sorry Daniel.domob wrote:I agree that deterministic builds are important, but what is really stopping us from simply running the source through a Python interpreter? I thought that's how it is supposed to be done anyway. With respect to a reproducible Python interpreter: What's the point if you can simply use the one bundled and signed by a major distro? You have to trust "some" component of your OS anyway.biolizard89 wrote:Reproducible builds are very important, and I don't think Joseph or I want the project to be completely dependent something that Tor devs were unable to do with several orders of magnitude more funding.