Factoshi

Alex

Factoshi
I'd like to make a small amendment to our application. In section 4.3(i) of our manifesto, we state that I will be running for Testnet Admin in the first election. I have since changed my mind and will therefore not be running for Testnet Admin.
 

Matt Osborne

Go Immutable
Exchange Working Group
Legal Working Group
Hi everyone. Can you do me a favor and breakdown the "Data Analytics" sub-section of the Ecosystem section? One of our biggest challenges grading apps is trying to distill who is just throwing pie-in-the-sky language out there and who actually has a well thought-out plan. This also will help hold teams accountable to campaign contributions. Therefore, the more detail the better. Solid overall presentation! Thanks
 

Alex

Factoshi
Hi everyone. Can you do me a favor and breakdown the "Data Analytics" sub-section of the Ecosystem section? One of our biggest challenges grading apps is trying to distill who is just throwing pie-in-the-sky language out there and who actually has a well thought-out plan. This also will help hold teams accountable to campaign contributions. Therefore, the more detail the better. Solid overall presentation! Thanks
Hi Matt,

We will have something more detailed for you by tomorrow. I need to confer with my partner as she is the data analyst.

Alex
 

David Chapman

Factomize
A. 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 I'm excited about) which is important even with your 50% Efficiency. The Standing Parties will likely want to see what development 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 success?
 

Alex

Factoshi
A. 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 I'm excited about) which is important even with your 50% Efficiency. The Standing Parties will likely want to see what development 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 success?
Hi David,

Thank you for your questions.

1. We will have a few different routes to communicate with standing parties. Discord has proven to be an excellent resource and will be one such route, but (as I know you are aware) it is not good for people who do not visit regularly. As such, we will publish our major releases via a Medium blog, which has proven itself a gold standard within the crypto community. We can post both those blog posts and lesser communications on Reddit and www.factomize.com.

We will also likely approach Matter of Fact for large developments to see if they are interested in publishing a press release. Our own website, www.factoshi.io, will not be suitable for blog posts, but we may link it directly to Medium.

2. As you know, I am a very active community member. Therefore, a lot of information will naturally flow to the community through the normal course of discussion. I am highly available in Discord, so if anyone wants to ask us a question they can do so very easily. This will be an informal route to communication.

Formally, we will publish a monthly blog post which will give development updates. Here, we will highlight what we have achieved since the last update and what we plan to do before the next update. We will also use our blog to give an indication of the overall direction Factoshi is taking and our longterm goals. That will be posted via the channels highlighted in my answer above.

3. I'd like to break this question down into two parts. I want to talk about how the community can gauge progress, then how they can ultimately gauge success.

Objectively, progress can be assessed by watching our GitHub repo, which you can find at https://github.com/Factoshi. If we claim progress in our blog posts, evidence of that claim will be visible on GitHub. It is our proof of work. If there are a lack of substantive commits, the community should hold us to account for that.

As for success, two of our projects, the data analytics web app and our entry credit store, will be visible on www.factoshi.io. When those are live, we will have begun to hit some of our key milestones.

Initial success for our intellectual property tool will be its availability for download on GitHub as a finished product. Longer term, success will be adoption for use by SMEs, which can be measure by the number of times it has been downloaded, and how effectively it is channeling entry credit purchases to our website.
 

Niels Klomp

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

NK01)
Could you elaborate on the production servers your team has managed (amounts, OS-types, purpose)?
Unix/Linux, Ubuntu
Could you reread the question and provide me with the answers? Thx :)
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK02)
We have been running a mainnet node since November 2017. We have hit our >99.99% uptime target during that time.
How did you measure the %99.99 uptime? Does that include/exclude planned downtime?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK03)
We will introduce a dual firewall system on each of our servers with the aim of creating
redundancy should one fail.
Which dual firewalls will you be employing? Could you elaborate on the possible failure aspect you mention?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK04)
Our servers and security practices will undergo regular auditing to identify early any security
vulnerabilities that could lead to a breach. This will include file system auditing, service auditing,
and auditing of the procedural guidelines that must be followed when interacting with our
servers.
Could you elaborate on the auditing part? How will that be performed for instance? What does regular mean?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK05)
Factoshi will have at least one team member on call 24-hours a day to respond to any
unplanned downtime. We are geographically distributed between UTC+0 and UTC-5, which will
us assist us in managing our rota.
Unless you go to sleep at exact same times in your respective timezones and only sleep 5 hours, there is a period every day that you both will be a sleep. It also means that you both have to be on call 24/7/365. Do you think that is feasible? Please explain your answer
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK06)
SME Intellectual Property Tools
How will you make sure that the one doing the Factom registration is really the one with the IP? What if I stole your IP and registered it on Factom?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK07)
We plan to increase the liquidity of Entry Credits by by selling directly to end users. This has a
two-fold benefit. First, it reduces barriers to adoption of the protocol. Second, it will allow us to
monetise our open-source intellectual property application, thereby ensuring the sustainability of
Factoshi as a business.
Could you walk me through both cases? How would you be making money?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK08)
Could you walk me through the development costs in regard to your current job(s)? You mention DC willing to switch full time. You also? Or already from the start?

At what price level would you both be working full time? How would you compensate if price would drop considerably for 6 months for instance?
 

Alex

Factoshi
Hi @Niels,

Thank you for your questions. I can answer most but will need to get back to you for NK01 during working hours in NY.

2. The uptime measurement was an estimate. It does include planned downtime. The only time our server has been down since December was to apply the Spectre/Meltdown patch. It was down briefly at that time.

Looking at my records, the server has been up since the end of December. Four months is 2920 hours. It was down for around 15 minutes to apply the patch. So, that implies downtime of 0.0085%, which would put us above that 99.99% target.

3. We will be employing an interior and exterior firewall. Externally, we will use a firewall provided by our VPS service provider. Internally, we will use ufw. This differs from traditional dual firewalls, which are usually designed to create a DMZ. Our DMZ is is a function of the guard nodes, and does not result from the dual firewall architecture as it was discussed in our manifesto.

With regards to failure, this biggest threat is human error or oversight. We will always strive to take the utmost care when handling our servers, and especially when handling key security components such as the firewall. However, humans are fallible, so we have to design our architecture in such a way as to reduce the impact of human fallibility.

For example, during the early stages of the testnet, most people were not aware that Docker changed iptables rules to differ from those set by ufw until I highlighted it to the community. If that oversight had happened in a production environment, then an exclusive reliance on ufw would have been disastrous. Dual firewalls create redundancy.

4. We will audit system services monthly to ensure that no malicious or vulnerable software has been installed on our systems. Vulnerable software includes trusted services that have recently discovered security bugs. Audits will identify those vulnerabilities quickly so that we can apply patches.

We will audit security files to check they have not been unknowingly or maliciously altered. These are SSH config and key files as well as iptables rules. An example of how a file might be unknowingly altered again comes from the Docker iptables example: if an update to Docker overwrites iptables rules, we need to know about that.

File system auditing will also take place monthly, except where we have applied updates, in which case we will check the status of potentially vulnerable files during the process of updating.

5. We would not necessarily need to be on call 24/7/365. For example, my shift may finish at 10 PM UTC, at which point DC comes on duty (5 PM her time). If she is then on call for the next 12 hours, then I can take over at 10AM UTC. We can then reverse the role once per week or month, whereby she comes off duty at 10 PM her time, which means I would come on call at 3AM my time.

We will adjust our alert tool to reflect our rota.

6. If you stole our IP and registered it on Factom, then we would have to use conventional methods to prove ownership. For example, we would need to show the process by which the IP was created, which a thief would struggle to do.

The IP tool is not intended to replace existing processes. Rather it is only intended to complement them. It is another layer of digital proof.

7. The dual token system is one of Factom's key features. Businesses can purchase entry credits directly, safe in the knowledge that they know exactly how many commits they will be able to make to the blockchain. However, that fails where there are a lack of suitable vendors selling entry credits. They would then need to go to the market and buy factoids for conversion. This introduces exchange risk, regulatory risk, and the risk of theft.

Supplying entry credits to businesses makes it possible for them to use the protocol where they would not have been able to if converting from factoids. Our target market will be the UK, where GBP is currently underserved by Factom Inc's entry credit store.

With regards to the second part of your question, we can make money by offering entry credits at a markup to the price we paid for them. Channeling purchases from our open-source application will create recurring revenue.

8. I am currently living from cryptocurrency gains made during 2017, so I am available to work full time from the outset. If the price drops considerably and for a prolonged period, I can continue to sustain myself comfortably for a long time.

In terms of price level, DC would be able to switch to working for Factoshi immedaitely. However, given the apparent instability of the Testnet and how soon that code will be applied to the Mainnet, we believe it reflects good planning and financial responsibility for her to remain in her current role until the network has proven itself stable and Factoshi has built reserves of fiat currency. She also has responsibilities to her current employer that need to be fulfilled.

In the event that Factoshi is her sole source of income, then a sustained drop in price that depletes Factoshi's reserves would require her to seek new sources of income outside of Factoshi.
 
Last edited:

Alex

Factoshi
@Niels

1. DC managed production servers for 5 years in the early 2000s for a film and television production company. She managed two Windows 2000 servers, ten Redhat Linux servers, and the corresponding Cisco routers. The purpose of the servers were mail and web services, steaming media, and VFX. The objective was essentially to manage networking between east and west coast offices.
 
Top