Thread for discussing the application of Factomatic LLC for operating Authority Nodes. We are happy to answer your questions!
Hey, David! Valentin here. The extra money will go mainly towards ramping up in-house development. Since the initial grants will be hardcoded in the protocol and since in our opinion there is quite a bit of legal ground to be covered for the proper operation of the Grant Pool, we believe it will be at least a few months before grants are given out to Authority Node operators or other entities in order to develop applications on top of the protocol. In the meantime, we would be using the extra money in order to get several developers to help us in the development of the applications we talked about in our proposal. For example, we have a provisional agreement with one front-end engineer in Sofia to assist us with the UI for the Factom Explorer, if we are selected as Authority Node operators. We would be looking to add at least one back-end engineer to the team as well.Thank you for your application. First question:
A. I like your development ideas and overall plans. I can see why you have a 20% efficiency for one node. For both Authority Nodes together, your efficiency remains 20% for each node. Eventually, the Protocol will have 65 separate entities running one Authority Node each and you will have just one. If you’re able to operate your business with the 1st Authority Node at 20%, what are your plans for the extra income of the 2nd Authority Node as you’re maintaining that 20% Efficiency across two nodes?
Network isolation - we will be using multiple tiers of networks (for different purposes), using firewall rules on the cloud provider level, as well as network policies within our Kubernetes cluster. Everything will be denied by default, and access is going to be granted explicitly.
Could you elaborate on the Kubernetes setup and especially on how this would bring you the fault tolerance you are mentioning?We will also be leveraging Google’s Kubernetes Engine service, as we plan to orchestrate any potential
deployments using Kubernetes to ensure high availability and fault tolerance of each individual
We estimated our break even for the operation of one Authority node at a price of $1.80-2/FCT. This factors our cloud hosting costs as well as potential and very rare cases where we might need the services of a 3rd party to temporarily maintain the service in case of unavailability of multiple team members (due to sickness or other excessive circumstances).With your stated efficiency of 20%, at what USD price does FCT need to be for your Authority Node operation to break even on a monthly basis (with one server)?
Good question. We plan to be involved in two tracks of development: open-source applications and proprietary software for clients and industry partners. The two will require different means of communication.B. Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you also discuss additional development work which is important since your single node Efficiency is set at 20% AND you plan to eventually file for grants. The Standing Parties will very much want to see what progress you're making since it was part of your campaign. My questions are:
1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.
2. What would you communicate and how often?
3. What metrics should be used to gauge your development progress and success?
When we talk about the network effects of Factom, we see this playing out on two levels:Could you elaborate on how you see Factom's network effects playing out? Thanks
To clarify: we have 4 people able to manage servers with the team, but not all of them are system administrators. Below you can see the breakdown by person.Thank you for your application
In your application you state to have 4 system administrators with a combined experience of 25 year. Could you break this down in members with their respective amount of years running production servers?
I’ll start with your last question - yes, we will be, and, in fact, we already have the code fleshed out and committed to a git repo. We used this code to experiment with the sort of setup before we did the final decision to go that route, and we also did some failover testing as well (to make sure it behaves as expected and that it takes little time to restore the service).NK02)
Could you elaborate on the Kubernetes setup and especially on how this would bring you the fault tolerance you are mentioning?
What if there will be no docker containers for mainnet?
Will you be using scripting or other techniques to create the kubernetes descriptors?
That is a good question and we have indeed considered this scenario. I would say that the main one would be potential incompatibilities between factomd and our setup. It is quite dynamic, and there are hardly any static configs applied. We know how to deal with that, though, so it won’t cause us major problems. We are hoping to further lower the likelihood of this occurring by closely following the development of factomd and providing input, be it in the form of feedback, or pull requests.NK04)
Like that you guys are playing with Kubernetes. Wanted to play with it as well, but somehow don't have a lot of time lately
Are there any negatives you could think if when you would be running in production in the future with kubernetes?
We estimated our break even for the operation of one Authority node at a price of $1.80-2/FCT. This factors our cloud hosting costs as well as potential and very rare cases where we might need the services of a 3rd party to temporarily maintain our operation in case of unavailability of multiple team members (due to sickness or other excessive circumstances).NK03)
You are with quite a large team. You explained the deferment. What would be the minimal FCT price for your organization to run without a los while operating one node?