biolizard89 wrote:So, I was intending to have a lengthy IRC discussion about ncdns project direction and management, but that failed to materialize, so I'm just going to put some thoughts here.
Point 1: We should try to evaluate the arguments that have been put forth about ncdns compared to NMControl. In particular, reproducibility of builds, and better compatibility with the DNS specs. I'd definitely like to see reproducible builds happen for ncdns sooner rather than later. Also, better install scripts would be good -- particularly relating to the installation and configuration of dnssec-trigger and Unbound.
I have added support for building without cgo.
Code: Select all
$ go install github.com/hlandau/ncdns
$ strings bin/ncdns | grep /tmp
(non-deterministic tmp paths)
# No cgo:
$ cp -a /usr/lib/go go-nocgo
$ GOROOT=`pwd`/go-nocgo CGO_ENABLED=0 go install github.com/hlandau/ncdns
$ ldd bin/ncdns
not a dynamic executable
$ strings bin/ncdns | grep /tmp
/tmp
$ sha256sum bin/ncdns > ncdns.sha256.1
$ touch src/github.com/hlandau/ncdns/main.go
$ GOROOT=`pwd`/go-nocgo CGO_ENABLED=0 go install github.com/hlandau/ncdns
$ sha256sum bin/ncdns > ncdns.sha256.2
$ diff -u ncdns.sha256.*
$
When not using cgo, the following restrictions apply:
- Privilege dropping is not supported at all on Linux.
- UIDs and GIDs must be specified numerically, not as names.
- No supplementary GIDs are configured when dropping privileges (the empty set is configured).
- setproctitle is not supported.
Point 2: Pull requests should be evaluated by multiple people prior to merging. Lack of interest in testing things is not an excuse for merging code that doesn't have sufficient ACKs. I was informed by a lawyer that we should expect attempts to sabotage our code -- multiple reviewers is the most effective defense against this. I don't know details of how the Bitcoin Core devs handle things, but their process seems to work pretty well, and I don't see a reason to deviate from what they do. Anyone particularly familiar with how Bitcoin Core does things?
Agreed. It looks like Bitcoin Core just has people post approvals in a PR.
Point 3: In terms of ncdns project leadership, I'd favor having three project leads: Hugo, Phelix, and myself. (That's assuming Phelix has an interest.) Other Namecoin devs should be included in the process. We also should be trying to encourage outside contributions. For example, Greg Slepak from okTurtles should be encouraged to submit pull requests to ncdns rather than work on the dead end that is the DNSChain codebase. Political issues should be left out of this equation, as with Bitcoin. It goes without saying that people other than Hugo, Phelix, and myself should also be reviewing code and design choices; "project leads" != "the only heavily involved people".
Sure.
Point 4: We should compose a feature matrix of ncdns, NMControl, DNSChain, and NamecoinToBind, and put together a plan for bringing ncdns any features that are missing. A REST API seems particularly relevant here. DNSChain and NMControl both have sucky REST API's; this is a good chance to standardize on something better.
I'm not convinced that namecointobind needs to be maintained. It should be trivial to use ncdns's conversion code to dump a zone file.
Point 5: ncdns should support the newer Namecoin Core features like REST, block/tx callbacks, and unconfirmed name ops.
Sure.
Point 6: ncdns should disable by default all d/ spec features that don't have full consensus from developers. Enabling such features was fine when ncdns was basically a playground for prototyping the spec, but if it's going to become an official Namecoin project, it's a very bad thing because it encourages websites to build on things that we will want to change later. The features that come to mind immediately are alias, translate, and all of the non-DNS types. A simple command-line flag "--enable-beta-spec-features" seems to be a decent way to enable such features for people who know what they're doing.
Since ncdns serves... DNS, I'm not sure what you have in mind in terms of disabling non-DNS types? I'm against disabling alias and translate; they're standard parts of DNS. How do you expect alias/translate to change later?
Point 7: Documentation should be produced for namecoin.org. The new Jekyll site should make this much easier.
Sure.
Point 8: The request by Greg Slepak to keep things blockchain-agnostic should be taken seriously. Ethereum seems to be pursuing a naming system; we should be aiming to collaborate with the Ethereum devs on areas of common interest.
Agreed. However, I don't think there are any codebase implications at this time. There's no point adding an abstraction layer until we have some concrete alternative to work with; otherwise the requirements of the abstraction layer and any "impedence discontinuities" it will need to work with are unknown. Abstractions developed under such conditions tend to suck.