Go Immutable

David Chapman

Factomize
Thank you for the application. To start:

A. From what I ascertain, you will be working to educate, understand the needs of, and onboard large enterprise clients. However, I don't see you mention that you'll be developing any applications on top of the Factom Protocol yourselves. As such, do I understand that you'll be working to funnel these clients to existing and future application providers on the Factom protocol?
 

Greg Forst

Go Immutable
Thank you for the application. To start:

A. From what I ascertain, you will be working to educate, understand the needs of, and onboard large enterprise clients. However, I don't see you mention that you'll be developing any applications on top of the Factom Protocol yourselves. As such, do I understand that you'll be working to funnel these clients to existing and future application providers on the Factom protocol?
Hi Dave. First thanks for stepping up to be a guide. I know you guys are unsung heroes and at other times take the brunt of issues.

-- Answer --
We have the ability to build on top of the Factom blockchain and plan to do so in the future. For example, the prescription drug tracking company, Appriss. We seek to develop an application for Appriss Health to create the first blockchain solution for prescription drug monitoring. State law mandates that every pharmacy is required to monitor and track the sale of specific prescription and non-prescription drugs in order to not only prevent overprescribing of controlled medications but also to help improve patient care and clinical outcomes.

However, we also plan on working with the competent developers in the Factom community. Basically, our plan is to figure out EXACTLY what enterprise clients need first and then build it (or team-up), as opposed to an “if you build it, they will come” model.

What we feel sets us apart from other authority set applicants is that we have the ability to open doors to enterprise clients and government agencies because we already have these relationships in place. As a result of consulting these clients, we also know the solutions for which they are looking.

Thanks
 

David Chapman

Factomize
B. Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you promise a lot more which is important despite your 50% Efficiency. The Standing Parties will likely 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?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
Thank you for your application

NK01)
A seamless failover process is being developed to insulate the end user from any degradation. This will include identifying issues before they cause downtime and preemptively rolling to backups to avoid downtime.
Could you elaborate on the above?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
I have a good idea about your infrastructure, but it could use a little more explanation

NK02)
The two auth instances per region. One is an active Auth node and the other is a follower for Blue/Green deployments and brainswaps? If not could you elaborate?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK04)

You use a HTTPS loadbalancer. Could you elaborate on the ports you are loadbalancing? What type of algorithm will the loadbalancer use? What is the goal?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK05)
You are applying NAT. Could you elaborate on the type of NAT you will be using and to what nodes you will be applying NAT?
 

Greg Forst

Go Immutable
B. Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you promise a lot more which is important despite your 50% Efficiency. The Standing Parties will likely 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?
1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.


We feel accountability is essential in all aspects of life, but even more so in a decentralized environment. In fact, we’d argue it’s absolutely critical. We’ve talked internally about this problem and come to the conclusion that the only way we can ensure accountability by all parties is if their is a central platform (yes, we realize the irony) that tracks every entity’s progress. We feel using trello, a blog, or Medium will not suffice. Video updates (or twitch) is probably asking too much. What we want to avoid is creating yet another firehose (discord, twitter). We also feel that we need the ability to get somewhat granular (tracking milestones and timelines). Point being, we need to create a platform (and process, such as monthly emails to entities), that can record everyone’s progress. That way, the Factom community can easily hodl every entity accountable. Constructing/identifying this platform is near the top of our list of “early contributions to Factom.”


2. What would you communicate and how often?


Developing a solid relationship with the community is a “must.” We strongly believe in network effects, and if we want network effects to take over, then we need to set a positive example. We’d strive to keep the community updated on any relevant news. We are using Basecamp for project management and will be using something like Trello, Asana or Jira for development projects. Additionally, we may use a CRM to track relationships and progress. All of these items will allow the Standing Parties to keep abreast of our progress.


Drilling down further, we’d use the litmus test: “If I were part of the community, but not part of Go Immutable, would I want an update?” If the answer is yes, we will post a quick update. Simple examples would include: sprint completions, client meetings scheduled, client meetings executed, new partnerships, advisor feedback, development updates, etc. In conclusion, we would get granular, but not obsessively granular.


3. What metrics should be used to gauge your development progress and success?


Progress needs to be measured by stating milestones and hitting milestones. We may be decentralized, but that does not mean that best business practices no longer apply. Entities need to be held accountable, period. Transparency is crucial. Set milestones, hit milestones. That’s how it works.
 

Greg Forst

Go Immutable
C. I noticed that jcheroske is listed on your application as well as another application. Can you explain?
As with all start-ups, things can be volatile. They change quickly. Matt O was previously working with a member of another entity. At that time, Jay Cheroske was their lead tech guy. Jay was brought in by the aforementioned member. Jay was responsible for spinning-up and managing servers for Matt, the member, and a handful of other entrepreneurs Matt had brought on board while everyone awaited clarity on how Factom would proceed regarding the Authority Set.


Unfortunately, the business partnership was not meant to be. Matt and the member parted ways with the following agreement: (1) Jay could continue working with Matt if Jay so chose (2) Matt would cover 100% of Jay’s development fees to date in the form of the member invoicing Matt for Jay’s past work (3) Jay would continue to support the member’s servers while the member transitioned to his new tech team, at no cost to the member. Jay continues to support the member’s servers as of today (April 27th)


Matt talked to Jay, and Jay enthusiastically came on board. Jay has been on Matt’s payroll for the past several weeks and they have an agreement in place for future work. Matt was under the impression that Jay was not supporting any other potential Factom Authority Set candidates.


Here is a high-level write-up provided by Jay regarding his last two weeks of development work for our team: “Tested alerts using both AWS and GCP alerting tools, but decided on consolidating the alerting onto GCP's Stackdriver platform. Wrote a script to perform brainswaps. Updated factomd across all nodes at least twice. Continued Ansible development, which mostly involved writing a small configuration management library and scripting the creation of a bastion host.”


If the Guides would like further clarification, we are more than willing to provide whatever information the Guides would like. We would also like to suggest that the Guides directly contact Jay.
 

Greg Forst

Go Immutable
Thank you for your application

NK01)

Could you elaborate on the above?
Hi Niels. Please see answers to your other questions for clarification. As specific security and infrastructure guidelines are finalized within the community, we will obviously adapt to agreed-upon best practices.
 

Greg Forst

Go Immutable
I have a good idea about your infrastructure, but it could use a little more explanation

NK02)
The two auth instances per region. One is an active Auth node and the other is a follower for Blue/Green deployments and brainswaps? If not could you elaborate?
Yes - the intention of having two Auth nodes is to allow for live environment swapping in the form of Blue / Green deployments. We want to minimize downtime as much as possible. Please see brainswaps answer.
 

Greg Forst

Go Immutable
NK03)
Could you elaborate on the follower instances?
We wanted to allow for brainswaps between unexpected failures of Auth servers with the followers to minimize downtime as much as possible. The entire intent of the overall architecture is to have a robust and fault tolerant implementation.
 

Greg Forst

Go Immutable
NK04)

You use a HTTPS loadbalancer. Could you elaborate on the ports you are loadbalancing? What type of algorithm will the loadbalancer use? What is the goal?
The Google Cloud load balancer will have TCP port 8110 health checks that will determine whether the NATs are up and running. We will also be utilizing the log collection engine depicted to determine anomalies in the backend infrastructure.


Apologies for the misnomer, I grabbed the load balancer block quickly and did not realize it had HTTPs.
 

Greg Forst

Go Immutable
NK05)
You are applying NAT. Could you elaborate on the type of NAT you will be using and to what nodes you will be applying NAT?
Google cloud doesn't provide a managed NAT service like AWS Nat Gateway, but the NAT would sit in front of all public internet traffic and obfuscate those requests from our production Auth and Follower nodes in the private subnet. As it stands today, Google requires the NAT VM to be debian based.
 
Top