Notary Application: Fleek

[jsonsivar]

Notary Application

PLEASE NOTE ANY APPLICATION SUBMITTED BEFORE THE FINALIZATION OF THE GOVERNING FIP OR THIS REPO WILL BE DISCARDED

To apply as a notary, please fill out the following form.

Core Information

• Name: Fleek
• (Optional) Affiliated Organization: Fleek
• Website / Social Media: fleek.co
• On-chain Address(es) to be Notarized: [Multisig to be supplied later]
• Region of Operation: North America
• Use case(s) to be supported: Web3 Developers & End Users
• DataCap Requested: 100TB

Please respond to the questions below in paragraph form, replacing the text saying "Please answer here". Include as much detail as you can in your answer!

Long Term Network Alignment

Time Commitment

Describe the nature and duration of your affiliation with the Filecoin project. Please include relevant Github handles, miner ids, significant projects or contributions (with links).

The Fleek team has been contributing to both the Filecoin and IPFS ecosystems since 2018. 

Fleek offers a number of services (Fleek Hosting, Fleek Storage, Space, Space Daemon and more) - all of which are used to help enable web3 developers and end users to seamlessly use products and services that leverage Web3 technologies under the hood (for more detail see our Github https://github.com/FleekHQ). Earlier this year, we were a Presenter Sponsor for HackFS, where our tooling was used to power a number of fantastic use cases(https://blog.fleek.co/posts/HackFS-winners). 

Stake Exposure

Please cite total token at stake (currently available, locked as collateral, vesting over time) and any substantiating evidence.

<No need to disclose, optional>

Industry Reputation

In-protocol Reputation

Please describe (in detail) your activity and tenure as a member of the Filecoin community. Please note (with links where possible) any contributions made to implementations of Filecoin, the spec, documentation, or to substantially help the Filecoin ecosystem grow.

Fleek has been an active contributor in the Filecoin ecosystem, supporting a number of the early adopters to make use of the Filecoin ecosystem. Our services bundle together popular tooling (such as Textile’s Threads, Buckets, IPFS, Filecoin) to reduce the friction in deploying web3 applications. In May 2020, we started working on tooling to integrate Filecoin into our stack to support early adopters. 


You can see more of our activity and contributions on our [Github](https://github.com/FleekHQ). 

In-protocol Security

Please describe your contributions to the security of Filecoin and the duration over which you've made contributions. Please also include any links or references who might be able to substantiate your contributions (e.g. if you've filed several bugs, please cite who you've communicated with on the Filecoin side).

None. 

External Reputation

Please describe the nature of your organization, including the country of registration, size of the organization, and time since inception.

Fleek makes it easy to build and integrate privacy, encryption, and p2p functionality into your sites, web & native apps. Built on top of IPFS, Textile, & Filecoin, our suite of products allow you to effortlessly take advantage of the benefits of these new technologies and abstract away the operational overhead required to use them. Our users use Fleek for building and hosting websites, developing Dweb Apps, storing data, and accessing IPFS through our gateway.

Fleek was founded in 2018, and we are currently a team of 13 people. Fleek is registered in the USA. 

Please share any relevant details to help substantiate information about your organization (website, named officers, links to social media profiles).

Website: fleek.co 
CEO: https://www.linkedin.com/in/harrisonhines
Twitter: https://twitter.com/fleekhq?lang=en

Please share any relevant external information regarding your organization (e.g. news articles, social media profiles, etc.)

https://blog.fleek.co/
https://www.linkedin.com/company/fleekhq/
https://www.helpnetsecurity.com/2020/10/01/space-storage/
https://twitter.com/fleekhq?lang=en
https://space.storage
https://twitter.com/spacestorage

Diversity and Decentralization

Use Case Diversity

(Optional) Any additional information you'd like to share about the use case(s) you plan to support?

We plan to support web3 developers building applications on top of Filecoin. Specifically, we hope to enable approvals for these early developers already using Fleek products (both now and in the future), so that their users are able to receive DataCap (if they own their own keys) in order to store data on Filecoin.

In the future we also might offer to support end users looking to store data on Filecoin. Specifically we would allocate a set DataCap amount to each new user of space.storage as a way to incentivize new usage of Filecoin storage, and potentially allocate larger DataCap amounts to paying customers and enterprises (if they own their own keys).

Allocation Plan

Concreteness of Allocation Plan

Allocation Strategy

How do you plan on allocating the DataCap requested above? Please describe your allocation strategy with as much specificity as you can.

As mentioned above, we will be targeting developers who have applications that themselves store data on Filecoin or allow their users to  store data using Filecoin. The goal is to enable early web3 developers with an easy on-ramp for acquiring DataCap for themselves and their users - to ease the development process and reduce the friction for services on Filecoin.

We intend to work with the developers to understand the following: 
Projected size of the application
Expected DataCap allocation per user
Which aspects of their app will be using filecoin (and how they will be using it)
Plan to ensure DataCap is used responsibly (deals across multiple miners with backups)
Given the relationship we have with web3 developers, we can vet inbound requests based on information developers provide in other forms (for example, when signing up to use our products). 

To enable all of this, we intend to run a version of the [Keyko service](https://github.com/keyko-io/filecoin-verifier-service/).

Are there any internal processes you plan on implementing regarding the target, amount, or rate at which you'll allocate DataCap?

For general web3 applications - DataCap allocation amounts will range based on the specific use cases outlined by the developers and the level of detail provided to us by them.  

For web3 developers that intend to get approved for enabling end-users to receive DataCap, we will determine appropriate values for DataCap rate per user, total DataCap per application, for each application, along with additional metrics that will be required based on the specific use case. We might also use their existing storage usage levels on Fleek or other storage platforms they currently use (ex. AWS S3) to determine their DataCap allocation. 

How do you plan on securing the DataCap to ensure your organization (and its delegated members) are the ones allocating the DataCap?

DataCap will be allocated from an address that is secured via a multisig. We will implement the `Keyko` service described in the automated notaries guide (https://docs.google.com/document/d/1Hns9DJa2Gh9punRCaUmYaMr6JF-1z8pMF3R0IEJ8gPo/edit#) on AWS infrastructure as illustrated in https://docs.google.com/drawings/d/1APGmuwQjVzj3x6NGr668WMHhRI8NMf9jzpeVJImiV90/edit. We will store the multi-sig keys in AWS KMS and run the transactions through a Lotus node on an EC2, all secured via AWS IAM.

Client Due Diligence

How will you vet your Client to ensure they are spending that DataCap responsibly?

For web3 developers that are using our hosting and storage services, as well as for those building on the Space Daemon and SpaceSDK, we plan to review activity on Fleek itself to monitor if applications are being abused by users to receive DataCap allocations. 

For some of our users, where we have stronger relationships (from longer usage of our other services, payment for other services, etc.), we already have a good sense of the reputability of these clients - and can educate them on best practices for using DataCap.

For other teams, we’ll be evaluating them based on the following factors and other information that they choose to provide to help substantiate their proposal:
Reputation
Track record of the team
Timeline of the project
Long term goals

What questions will you ask to ensure the Client can properly handle the DataCap you intend to allocate to them?

The main consideration for us will be in ensuring that the web3 developer has the appropriate tooling and metrics in place to ensure that whatever DataCap their users are pre-approved for is being spent in a responsible way (e.g. not biasing to any individual miner, making use of the suggestions at https://github.com/filecoin-project/notary-governance/issues/9, and so on). 

What processes will you employ to confirm that a Client is not improperly over-allocating DataCap to a single entity?

End users will generally receive a small DataCap allocation, which means the abuse space is quite low. Regardless, we plan on working with developers to ensure that allocations are being used in a responsible manner and the system is set up in a fair way. 

By using a service to allocate DataCap to the end-users, all approvals and allocations can be traced and analyzed to prevent misuse of the system. 

Bookkeeping Plan

Do you plan on keeping records of your allocation decisions? If so, with what level of specificity do you intend to respond to any audit requests?

Using the multi-sig architecture, all allocations will be visible on-chain. We would approve developers in public, but if we ever extend DataCaps directly to end users, we might anonymize their data in the public approval to protect their privacy (we will give users the option to opt in/out of sharing their info publicly for purposes of the DataCap).  

Do you plan on conduct your allocation decisions in public (e.g. Github repo), private (e.g. over email, Telegram, etc), or both?

Yes - we plan to use the same repository as the Filecoin Foundation and other teams. But related to the above answer, we might anonymize some data related to end-users in order to preserve their privacy (if they don’t opt in to sharing that info when being approved for the DataCap). 

Track Record

Past allocation

Have you previously received DataCap to allocate before? If so, please link to any previous applications.

None

Cumulatively, how much DataCap have you previously successfully allocated?

None

Have there been (or are there still) any disputes raised against you from your previous DataCap allocations?

None

[jnthnvctr]

hi @jsonsivar - based on your submission, we've scored your application here: https://docs.google.com/spreadsheets/d/17UP41lMMd-3J9no8xBVoPGkVPpeF4n_nimRT5LNXsAs/edit#gid=327015220

Eligibility score: 2
Unrounded score: 1.6

[jnthnvctr]

Hi @jsonsivar - as mentioned on the governance call yesterday, your team was in the top of your region for being a prospective Notary! Prior to confirming your role as a Notary, there are a few items that need to be affirmed:

1. Please acknowledge the region of operation in which you tend to primarily focus: [NA]

2. Please confirm each of the following items below (you can do this by adding a line under each section agreeing that you'll abide by these operational principles.

• Upfront Disclosures: Prior to being confirmed as a Notary, Notaries are expected to disclose all relevant addresses which they control, have a financial stake in, or are strongly connected to by other means. For the disclosure, the Notary should state the relevant addresses and the nature of the relationship.

• Promoting Client Best Practices: Notaries agree to educate approved clients about the best practices for using their DataCap (e.g. how to request additional services from miners, storing data redundantly across many miners, etc). Some reference information can be found here.

• No Self Dealing: To prevent conflicts of interest, Notaries should not allocate DataCap to Clients over which they control the private keys, or to a Client who intends to specifically spend the allocated DataCap with an address affiliated with the Notary. When in doubt, Notaries should bias towards transparency (i.e. public disclosure) or to getting a different Notary to handle the individual request.

• Operating in good faith: Notaries hold a position of trust in the network, and as such it is expected that they operate keeping the Principles of this mechanism in mind. While each form of abuse cannot be exhaustively defined, Notaries are expected to bias towards caution and act in a way that promotes transparency. Notaries should expect to potentially receive requests or questions for allocation decisions (within reason) - and should make decisions with this in mind.

3. Please list any addresses you are affiliated with below - stating the nature of the relationship. Please refer to the first bullet point in (2) for the definition of "affiliated", and bias towards transparency when in doubt.

4. Please affirm that you will abide by the allocation / client due diligence plan you laid out above.

5. (If ready) - Please confirm the address that should receive DataCap.

[jnthnvctr]

Additionally, if you plan on being listed in the Filecoin Plus Registry - please confirm what information you'd like to have displayed below.

"name": "Your Name",
"use_case": [
"List",
"of",
"Use Cases"
],
"location": "EUR",
"github_user": "notaryc",
(optional) "website": "google.com",
(optional) "max_datacap_allocation": "100 GB", // To indicate to clients what size allocations you might support.
(optional) "private_request": "false", // set as true if you plan on supporting private requests.
(optional) "email": "[email protected]", // only needed if you are supporting private requests
"info": "" // You can use this to share information with Clients about your allocation strategy / reqs

[dkkapur]

@jsonsivar - when possible, please explicitly acknowledge and confirm the previous points raised by @jnthnvctr so we can proceed with confirming you as a Notary.

[jnthnvctr]

@jsonsivar - ping!

[jsonsivar]

@jnthnvctr & @dkkapur - here are the confirmations:

"name": "Fleek",
"use_case": [
  "static site hosting",
  "file storage",
  "archive backups",
],
"location": "NA"
"github_user": "harrisonhines , jsonsivar, studna",
(optional) "website": "fleek.co",
(optional) "private_request": "true", 
(optional) "email": "[email protected]",
"info": "Fleek provides web3 development infrastructure primarily focusing on static site hosting and file storage."

Please acknowledge the region of operation in which you tend to primarily focus: [NA]

Confirmed.

Please confirm each of the following items below (you can do this by adding a line under each section agreeing that you'll abide by these operational principles.

Upfront Disclosures: Prior to being confirmed as a Notary, Notaries are expected to disclose all relevant addresses which they control, have a financial stake in, or are strongly connected to by other means. For the disclosure, the Notary should state the relevant addresses and the nature of the relationship.

Confirmed.

Promoting Client Best Practices: Notaries agree to educate approved clients about the best practices for using their DataCap (e.g. how to request additional services from miners, storing data redundantly across many miners, etc). Some reference information can be found here.

Confirmed.

No Self Dealing: To prevent conflicts of interest, Notaries should not allocate DataCap to Clients over which they control the private keys, or to a Client who intends to specifically spend the allocated DataCap with an address affiliated with the Notary. When in doubt, Notaries should bias towards transparency (i.e. public disclosure) or to getting a different Notary to handle the individual request.

Confirmed.

Operating in good faith: Notaries hold a position of trust in the network, and as such it is expected that they operate keeping the Principles of this mechanism in mind. While each form of abuse cannot be exhaustively defined, Notaries are expected to bias towards caution and act in a way that promotes transparency. Notaries should expect to potentially receive requests or questions for allocation decisions (within reason) - and should make decisions with this in mind.

Confirmed.

Please list any addresses you are affiliated with below - stating the nature of the relationship. Please refer to the first bullet point in (2) for the definition of "affiliated", and bias towards transparency when in doubt.

None.

Please affirm that you will abide by the allocation / client due diligence plan you laid out above.

Confirmed.

(If ready) - Please confirm the address that should receive DataCap.

f0121930 f2lda563hy3q2oxnoo265elynct3u2ft27ae7ptfy

[jnthnvctr]

Thank you for this!

Request Approved

Address

f2lda563hy3q2oxnoo265elynct3u2ft27ae7ptfy

Datacap Allocated

100TiB