🔗Question 1: In general, what are the restrictions combined with deploying on and using the DADI network. Compared to for example Azure?
I wouldn’t say there are restrictions. we’ll provide mechanisms that will make the deployment of a service to thousands of hosts across the network as simple as (or simpler than) what it’s like to deploy a site to Azure at the moment. the fact that the network is decentralised may seem daunting from a devops perspective, but we’ll create the tooling to abstract all that complexity from the end user
Talking more broadly, we will be releasing our web services one by one — starting with DADI CDN.
This is a conscious decision to enable us to get to mainnet launch faster than would otherwise be possible, and to provide clarity of purpose as we go to market.
🔗Question 2: When was the first time you had the idea to create DADI (the fog-computing part)?
My business partner Chris and I first discussed the potential for doing something a little different in February 2016, which was when the concept for a decentralized stack was born. Before this our web services had always been intended not be launched as a “traditional” cloud.
The key thinking in the first instance was about how we could get content as close to the end user as possible. We’ve run cloud setups for clients for years, and one common thread has been the difficulty in providing the best possible experience in terms of load time and responsiveness to audiences around the world. You can do a lot with an AWS, but their reach remains pretty limited. So the thought was “what would happen if we could put a node in every local loop of every ISP in the world?”
Of course this would only possible through the cooperation of 10’s of thousands of individuals, and how do you go about organising that sort of community? Trust has to be handled within the network. So the blockchain is linchpin of the idea. It enables trust between strangers, and brings proof of stake, trust metrics, payment audits, and proof of availability to the table as well — enabling a marketplace that can exist on its own, without a single central controller.
🔗Question 3: Will DADI have any tools to help migrate corporate websites running on legacy IIS example IIS 6?
In short, yes. we’ve been building tools that can help with this.
There are multiple aspects to a migration from an existing platform to the DADI suite of web services.
The main one is migrating the data into DADI API, which depends a lot on what type of data store the existing project uses. we built a series of tools to automate migration of data from various systems, so changes are we can provide you the tooling to ease the process.
Then there’s the template layer, which again depends on what the existing technology looks like. because DADI Web supports virtually any template engine, it may well already support your language of choice, meaning that changes required are minimal.
- If it doesn’t, it’s pretty simple to build support for it
🔗Question 4: In order to reach mainstream adoption, the token must be easily available for consumers. What will be your approach on this?
There are a couple of approaches to this.
Exchange strategy. It’s important that tokens are easily accessible and part of this is ensuring enough coverage with exchanges. We were quick out of the gate on this front, but there’s more to be done. To this end we have a VP of exchange relations retained. However we cannot put timeframes or names to this side of things.
Ease of accessing services. It is essential for business customers to be able to purchase services in ways that they are already used to. This means traditional payments in fiat (e.g. Visa/Mastercard).
We will be providing this via a relationship with a payments provider and a micro-exchange that is being built in to our website.
🔗Question 5: Will the nodes need to be on a fixed ip?
The Stargate and Gateway nodes will be, however the beauty of the method we employ for Host > Gateway interactions means that not only do the Hosts not need a fixed IP, but multiple Hosts can operate behind a single IP address.
🔗Question 6: Are there plans to organise meet-ups worldwide and get people to know about DADI?
Yes — we are planning to attend many of the upcoming blockchain events (much as we did with Consensus last week in New York), both to have a visible presence and to arrange to meet partners and community members. For example we’ll be at Unchain, DeveloperWeek New York, London Blockchain Summit, Blockchain Summit Singapore and Blockchain Live.
We are also working on making every other AMA a physical meet up at locations around the world.
🔗Question 7: Why do we still need computing resources based on DLT, since there is already IPFS, bigchaindb etc? How will DADI compete with these?
It’s difficult to compare. IPFS is a protocol (which we’ll actually use in some of our products), bigchaindb is a DB storage engine. DADI is a whole suite of web services or, if you like, a set of modular pieces that allow you to assemble websites and applications as complex as you like.
Building the various pieces as well as the network they run on is quite a powerful combination, and that’s what sets us apart from any existing proposition.
To your point, your examples are part of the solution, not a solution in and of itself.
🔗Question 8: What will node payouts be?
Node payouts will vary by node type, with Stargates earning more than Gateways, which in turn more than Hosts.
There’s a balance to be struck between the on-boarding of nodes and the onboarding of customers. Overreach on the one hand and payouts will be diminished. Overreach on the other and we may not be able to meet capacity requirements.
To manage this we will be controlling rollout in the first instance — opening the gates to node contributors slowly at first and speeding up over time. Customers will be on-boarded directly as well, with online signup not due until the end of Q4.
Specifics relating to expected return on POS will be announced in early June.
🔗Question 9: What made you choose NSQ as opposed to RabbitNQ or some of the other well established messaging queues?
There were a whole host (excuse the pun) of performance factors that we evaluated during the benchmark phase, prior to selecting NSQ as the primary candidate for the messaging queue.
The network applications are built with Golang, and the fact that NSQ was one of the initial reasons it made the shortlist. RabbitNQ relies on the Erlang runtime, so another moving part outside of the core codebase language.
It also persists data when there are no connected hosts, which allows us to take the core monitoring services offline without losing valuable logs.
The topology is, by design, horizontally scalable and will cluster and scale much better than RabbitMQ. So far, it’s been exceptionally performant, and the results of our benchmarking are promising.
🔗Question 10: Do we know if setting up nodes will require high-end rigs? Or will regular VPS machines suffice?
DADI Host runs extremely well on low-power machines, and is specifically designed to do so. We’re targeting support for a wide array of devices, including mobile phones and laptops.
Gateway and Stargates require exponentially more power, as they handle far more in the network than individual Hosts.
So in answer to your question, yes, regular VPSs will be able to be used to contribute to the network.
🔗Question 11: Can you use DADI web services for more than just websites?
One of the key strengths of our web services is that they separate functionality in discrete, modular pieces, that communicate with each other in a technology-agnostic way. in practice, this means you can create a piece of content once and then serve it to any medium you can think of, be it a website, a native mobile application, a smart TV app, etc.
You can read more about the potential of this approach at https://medium.com/dadi/dadi-and-api-first-development-189b37bed704
It’s worth noting that by using the network you are by definition decentralising your product. This + our integration with various chains makes DADI the perfect platform for dapps.
🔗Question 12: What made you choose to stop using Zookeeper in favour of Consul before the mainnet launch?
Zookeeper scales really well for a lot of rather large operations, including Rackspace, Yahoo and eBay. Adam K Dean, one of our network engineers wrote an article about the switch which he’ll be publishing soon, possibly tomorrow.
To give you an abridged answer, it’s all about write speed. Zookeeper is fantastic for heavy reads across multiple nodes, but when it comes to write, it starts to exhibit some potentially blocking latency issues.
As we introduced a finite state machine into network applications, there was a sharp increase in the demand for writes. By switching to Consul, we have better control over device discovery, as well as a more granular set of states for the network apps.
🔗Question 13: What will be the necessary steps for someone who wants to run a host? Do you think that my mother, who finds it very hard to use Facebook, will be able to set and run a host?
We’re working to make this as simple as possible and to this end have been developing interfaces to lead contributors through the process. We’ll share some of this work next week.
🔗Question 14: What is the difference between DADI and HeroNode?
HeroNode is a development solution for DAapps, with a focus on file storage in support of the decentralised applications.
Like HeroNode, the DADI Network will handle storage, but a key point of difference is that the DADI network provides not only a network to run web services, but the web services themselves, which have been in production for ~4 years. We’ve been building a suite of discrete web services that allow developers to build performant, flexible and scalable websites and applications and get them to production at incredible speeds. The modularity offered by our microservices stack lends itself perfectly to a decentralised setup.
In plain terms: whilst other companies are building generic decentralised networks in the same way that computer vendors create generic hardware, we create a decentralised network and a suite of microservices that work in symbiosis, in the same way that Apple is able to produce both their hardware and software together.
🔗Question 15: Are you able to share names of a few strategic customers who plan to immediately transfer over to the new distributed cloud services once the mainnet is live? Are most current customers planning to migrate?
I can’t name names yet, but I can tell you that we have commitments from the majority of our existing customers, as well as some new business lined up for the rest of the year.
🔗Question 16: How will you prevent DDOS attacks?
Network scale is a big part of the answer here. But we’re also working with partners to build scrubbing centers into the backbone of the network, which will go a long way to protecting us from DDOS attacks.
🔗Question 17: What are some new use cases your team is exploring for the near future?
Much more detail to come on this when our new website launches, but in the meantime highlights include content management and publishing platforms, content manipulation and distribution (CDN), developing mobile and tablet apps, paid subscription services, customer relationship management (CRM), content personalisation and machine learning. Oh and cheaper cloud services! To name a few… :)
🔗Question 18: What’s new in CDN 3.0 and what makes it network-ready?
CDN is the first product to launch on the DADI network, so for the 3.0 release we focused our efforts on making sure it’s optimised for a decentralised setup. There’s a lot happening in the new version, but the main points are
Support for multiple domains with individual config/workspace directories, which allows a single instance to serve multiple projects and therefore optimising computational resources of nodes
Changes to the authentication layer to support the decentralisation of issuing bearer tokens
We also throw in some significant performance improvements, using feedback from the extensive tests we’ve been doing with our testnet. we’re releasing an article alongside the product release next week with full details.
🔗Question 19: What are your plans for marketing?
We have traffic driving campaigns for all major channels lined up (and gearing up), along with a PR campaign (we appointed a global PR firm two weeks ago) and an events schedule. We’ll publish an update to the marketing plan shared during the Crowdsale in the next few weeks for reference.
🔗Question 20: Will anyone be able to block the IP addresses of the DADI network?
At any given time there will be a lot of Gateways in the network. The IP addresses would prove very difficult to track, as we expect to see Gateway nodes joining and leaving the network regularly.
It is true that governments have the power to block at DNS level, which would affect individually hosted sites, but the nature of the network makes it incredibly difficult to target the network infrastructure.
🔗Question 21: What do you feel is going to be the biggest challenge for DADI going forward?
We’re very happy with the technology, and have overcome all of the major hurdles that a step change like this represents. As such our largest hurdle is awareness: how do we drive network use?
Happily we have a bunch of strong answers to this, most of which will be being put into effect between now and the end of the year.
🔗Question 22: When can we contribute to the network?
We’ll be publishing a schedule for this towards the end of May. So watch this space!
🔗Question 23: How is mainnet development going? Is the release date finalised?
Very well. We’ll be live in Beta at the end of June.
🔗Question 24: How big is the testnet?
We have around 20 nodes in the testnet at the moment, spread around the world, and have tested with hundreds of thousands of virtual nodes.
🔗Question 25: Do you have plans to implement a real-time, low ping (as hosts are all around the world)? Let’s say for games?
The focus on geographic matching of web service consumers to service hosts mean that whilst traditional cloud hosting offers a fairly high number of hops, albeit on a fast line, the DADI network pairs for the shortest hop distance.
In short, when you access a website, it could be hosted by your neighbour.
🔗Question 26: You are giving a payout per hosts. Depending on the app deployed on the host, cpu & memory & bandwidth requirements per hosts will vary a lot. Are we able to set a host rich of bandwidth and low on cpu? Do you allow customisations like that and do you have plans to reward more for more intensive hosts?
The network is aware of the capacity available and the capacity committed at node level. This information is used to inform node selection per-request, as well as to structure payouts on the basis on contribution.
🔗Question 27: Regarding the new website… what is your approach to getting listed as high as possible in relevant Google rankings?
There’s a lot of smoke and mirrors out there in relation to SEO.
Our approach is fairly simple: produce strong, well worded content about relevant topics and back it up with well structured HTML. In addition to this, where we are not yet ranking, we will employ adwords to ensure exposure at the top of search results.
🔗Question 28: Can I replace my Dropbox subscription with DADI soon?
DADI Store will move to Beta in the next month or so, and will be released to the network in the next few quarters. So yes.
🔗Question 29: Is the new website going to be hosted on the DADI network?
Yes. Yes it is.
