fible1 said: Where will the server be hosted? Who will be carrying out the build? Click to expand...

fible1 said: My main concern is that we should keep our startup spirit and be as frugal as possible Click to expand...

balu said: we should totally go with renting a server instead of buying one.This would cost less, is better cash-flow wise (no initial investment), would require no hw maintenance (less burden on our core people), and will enable us to upgrade later way easier. Click to expand...

crowning said: what was the reason why we don't run our own mail server Click to expand...

n00bkid said: If a new development team ever gets voted in, what happens with the $3k hardware? Click to expand...

We haven't decided yet, but either I or @flare will be performing the build and co-locating the server near whomever builds it.Thank you for saying that, I appreciate it!That is the goal in mind. I've scratched out plans for our billion-cap dream infrastructure, but would like a single, powerful box to handle most of the backend administrative processing in the mean time.I considered dedicated packages, but prefer the isolation that purchasing our own hardware affords.One of my goals in building the new infrastructure is high security with as little exposure to logical and social attack vectors as possible.I lean a bit extreme on the paranoid side, but it's served me well over the years.My intent with this first system is to build a secure base that compiles and deploys all artifacts and services to cloud instances using ipfs, docker, and rancher.With so much control in one system, it will only be accessible over a vpn, probably cjdns and only by a few community-trusted people. @eduffield @moocowmoo , and maybe a few others that need it. (For Evolution for example)As far as upgrades go, these specifications will suffice as a build system for years and years to come. I expect builds to take under five minutes per platform serially, with the capability to run several gitian builds in parallel, probably 3 at a time before any resource contention. This will allow us to go from commit to test suite completion to development version installation (automated mass testnet deploy) within a few minutes.I've spec'd this box fast and powerful to supercharge development cycles.I've also spec'd it huge (drive space) to be the first level of proper incremental backups. Not to mention docker images aren't tiny at the repository-mirror level.I like protonmail, we may end up there.But for now we've chosen google to unify administration of all the google accounts for google docs (which we use extensively).Because it's easier to farm it out for now.Running postfix/dovecot/spamassasin is easy enough, but providing a web interface isn't a priority at the moment.As far as third-party exposure goes, any communications that are sensitive are protected by gpg.Additionally we'd need several ip's for PTR records to guarantee 100% delivery for our multiple domains. Forwarding it solves this issue for the time being.I consider this server to be a step toward unifying the administration of the entire dash ecosystem.If a new development team were to be voted in, I'd hope they'd want to write code and leave the administration to someone already doing it. (Assuming I'm doing a good job, hehe.)---This path forward is how I've chosen to evolve our administration from a single openvz vps to something dynamic and manageable.Owning our own hardware guarantees that we always have a stable, secure base to manage all of dashs services and needs.Everything else will be reproducible, deterministic cloud deploys.I look forward to building us all a spectacular, reliable system!