Notary Application: Textile

[andrewxhill]

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: Andrew Hill
• (Optional) Affiliated Organization: Textile
• Website / Social Media: textile.io
• On-chain Address(es) to be Notarized: f2kb4izxsxu2jyyslzwmv2sfbrgpld56efedgru5i (f0103359)
• Region of Operation: North America
• Use case(s) to be supported: Web3, Web2 integrations, Data Warehousing
• DataCap Requested: 1PiB

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 Textile team have been long time contributors (since 2018) to both the Filecoin and IPFS project. Inside of Filecoin, we’ve built and support some of the most broadly adopted tools: 

Buckets: https://textile.io/#buckets
Powergate: https://textile.io/#powergate

Our tools and infrastructure are helping support a number of prominent teams in the ecosystem, such as Slate, Fleek, Voodfy, and more.

We are regular contributors to the community through PRs, workshops, talks, tutorials and blog posts. 

Stake Exposure

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

Please answer here.

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.

Textile has been an active contributor in the Filecoin ecosystem and in helping support a number of the early adopters make use of the Filecoin ecosystem. Both [Powergate](https://textile.io/#powergate) and its hosted version, [Buckets](https://textile.io/#buckets), are used to power applications with thousands of users, and abstract the complexity of running Filecoin away from end users. 

The Textile team has been an active participant in the Filecoin community, you can find a few examples of our contributions and engagement 

https://github.com/filecoin-project/lotus/pull/910 
https://github.com/filecoin-project/lotus/pull/911 
https://github.com/filecoin-project/lotus/pull/937 
https://github.com/filecoin-project/lotus/issues/1122 
https://github.com/filecoin-project/lotus/pull/1084 
https://github.com/filecoin-project/lotus/issues/1099 
https://github.com/filecoin-project/lotus/pull/1155
https://github.com/filecoin-project/lotus/pull/1159
https://github.com/filecoin-project/lotus/pull/1392 (2020-03-10) 
https://github.com/filecoin-project/lotus/pull/1452 (2020-03-26)
https://github.com/filecoin-project/lotus/issues/1455
https://github.com/filecoin-project/lotus/pull/1472 (2020-03-30)
https://github.com/filecoin-project/lotus/pull/1481 (2020-03-31)
https://github.com/filecoin-project/lotus/pull/1516 (2020-04-06)
https://github.com/filecoin-project/sector-storage/pull/38 (2020-05-19)
https://github.com/filecoin-project/sector-storage/pull/39 (2020-05-20)
https://github.com/filecoin-project/lotus/pull/1843 (2020-05-27)
https://github.com/filecoin-project/lotus/pull/2040 + https://github.com/filecoin-project/lotus/pull/2042 (2020-06-16)
https://github.com/filecoin-project/go-fil-markets/issues/292 (2020-06-23)
https://github.com/filecoin-project/go-fil-markets/pull/326 (2020-07-16)
https://github.com/filecoin-project/lotus/pull/2462 (2020-07-17)
https://github.com/filecoin-project/lotus/issues/2945 (2020-08-10)
https://github.com/filecoin-project/lotus/issues/3297 (2020-08-25)
https://github.com/filecoin-project/go-fil-markets/pull/429 (2020-10-09)
https://github.com/filecoin-project/lotus/pull/4584 (2020-10-26)
https://github.com/filecoin-project/lotus/pull/4650 (2020-10-29)
https://github.com/filecoin-project/lotus/pull/4808 (2020-11-11)
https://github.com/filecoin-project/lotus/pull/4827 (2020-11-12)

You can find a number of articles we’ve written dealing with Filecoin, projects built on Filecoin, or product features we’ve built for Filecoin on our blog: https://blog.textile.io/tag/filecoin/

We were strong supporters of Filecoin client onboarding activities such as Slingshot, where our team worked diligently to support dozens of projects that used Powergate to store data on the Filecoin network.

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).

Please answer here. 

External Reputation

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

Within IPFS and Filecoin our technologies are adopted within web3 - 

Registration: North America
Size of Org: 5-10 people
Inception: 2016

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

Website: textile.io 
CEO: https://www.linkedin.com/in/andrewxhill
CTO: https://www.linkedin.com/in/sanderpick
Twitter: https://twitter.com/textileio?lang=en

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

https://blog.textile.io/ 
https://docs.filecoin.io/build/textile-buckets/
https://filecoin.io/blog/community-andrew-hill-textile/
https://twitter.com/textileio 

Diversity and Decentralization

Use Case Diversity

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

Our aim is to support web3 use cases - specifically targeting developers who have applications that are enabling users to own their keys and want to store data using Filecoin. Given how DataCap allocations work in Filecoin (as a one-time credit), we need a scalable solution such that web3 developers can get their users “pre-approved” for DataCap allocations in order to avoid having to have each user individually request DataCap. 

By offering a permissioned system that will allow web3 developers to apply for DataCap on behalf of their users, we can “semi-automate” the approval process - and manage the allocation of DataCap based on the quality of the web3 developers’ tooling and processes. 

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, our aim is to support web3 use cases - specifically targeting developers who have applications that are enabling users to own their keys and want to store data using Filecoin. Given how DataCap allocations work in Filecoin (as a one-time credit), we need a scalable solution such that web3 developers can get their users “pre-approved” for DataCap allocations in order to avoid having to have each user individually request DataCap. 

Per application, we’ll work with the developers to get a sense of the size and scale of the application, the requested allocation per user, and strategy for ensuring the DataCap is being spent in a responsible way (decentralization across miners, storing redundant copies, requesting fast retrieval where applicable, etc). 

Based on the due diligence with the developer, we’ll make an allocation decision - both for the total DataCap that we’ll allocate to the application as well as the amount we’ll approve per user of that application (and re-allocate as the user requests more). 

To enable this we’ll be modifying the Keyko service (https://github.com/keyko-io/filecoin-verifier-service/), to integrate with our tooling. Practically the way this will work is that we will control a multisig (that will be made a Notary), and we will issue a token to approved web3 developers that they can use to propose to our service (which will enable an automated approval process that documents allocations on chain). 

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

Our aim is to support web3 use cases - depending on the detail and the quality of the information provided by the web3 developers, we may approve allocations of smaller or larger sizes for their use cases and the amount of due diligence to which the application developer can commit. 

Factors that will be considered are: 
- What sort of processes will the web3 developer use to ensure their app is not being abused
- For specific end users (who may have multiple addresses) what sort of rate limiting will be imposed

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. 

Client Due Diligence

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

For web3 developers using our hosted services, we’ll be reviewing activity on our platform to ensure that their applications are not being spammed to improperly receive DataCap. Given other considerations (e.g. bandwidth and other associated costs) we’ll have a strong handle and line of communication with these teams to make sure these services are being used appropriately (and will have a financial incentive to do so as well). 

For other teams, we’ll be evaluating them based on reputation, track record, and other information that they choose to provide to help substantiate their proposal. Examples include:

At what stage of development is the application (pre-release, beta, production with users)
Development team reputation factors (legal entity, DAO, university team, hackathon team, etc)
Relationship they have with their users (paying customers, token users, anonymous testers, etc)

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

In our situation, the end user (a user of Slate as an example) will be receiving very small DataCap allocations. 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 (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?

We will be able to monitor this based on the architecture of our approvals and service based approach to allocating to end-users. Because the end users are receiving a small amount of DataCap, the space for abuse is quite low - and we’ll work with the web3 developers to ensure they aren’t unfairly biasing their storage strategies in an abusive way. To abuse our setup, a developer will need to increase the requests for DataCap at which case we can more carefully monitor those applications making a high number of requests to mitigate any abuse. 

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 multisig architecture, all allocation decisions (from Notary -> end user) will be visible on-chain. We will make the application process closed but will open the acceptance to the public. This will allow us to work confidentially with projects that don’t initially meet the criteria for acceptance (e.g. to early in their development process) to help them improve. At the same time, making all details for newly accepted applications public will allow the community to monitor our results.

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

Final approvals will be in the same repository, yes. 

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 @andrewxhill based on your submission, we've scored your application: https://docs.google.com/spreadsheets/d/1pj7VRK3EUoT8PpPNwXZBRwtmtFwSeL2pcho-xdETcJ4/edit?usp=sharing

Eligibility score: 2
Unrounded score: 1.6

[jnthnvctr]

Hi @andrewxhill - 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, since you've indicated you plan on being listed in the Filecoin Plus Registry (and associated repository) - please confirm what information you'd like to have displayed here:

"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", // leave as true if you plan on supporting private requests.
(optional) "email": "youremail@a.com", // only needed if you are supporting private requests
"info": "" // You can use this to share information with Clients about your allocation strategy / reqs

[dkkapur]

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

[andrewxhill]

sorry for the delay @jnthnvctr & @dkkapur

"name": "Textile",
"use_case": [
  "App developers",
  "dApp developers",
  "API developers",
  "Data warehousing",
  "Long-term backups",
  "Scientific data",
  "Geospatial data"
],
"location": "NA", // If possible, we would be interested in adding SA here too since there were no existing notaries covering it.
"github_user": "andrewxhill, jsign",
(optional) "website": "textile.io",
(optional) "private_request": "true", // all accepted applications will become public
(optional) "email": "filecoin@textile.io", // only needed if you are supporting private requests
"info": "Textile's aim is to support web3 use cases - specifically targeting application, API, or infrastructure developers who are enabling users to store data using Filecoin. We will support both the common application type (one application with one address) and a multisig application where one application can verify a growing pool of users each with their own address."

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.

Yes, confirm.

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.

However, we want to provide details of our multisig setup to ensure that if we perform verifications in a way satisfactory to the community.

1. The Textile Hub user model is broken into two roles: Developer and App User.
2. We plan to accept applications from Developers for multisig-based quota for their app users. In this case, Developers will hold a private key off of Textile infrastructure.
3. When the Developer on-boards a new user and wishes to use Hub APIs with a hosted wallet address for that user, they will issue a request to our API for the notary to provision a small portion of their datacap directly to the end user's wallet.

In the setup above, we will be dealing with the applications from Developers and accepting those applications in the public with their public keys listed in the application. In cases where the app user's wallet (that exists on Hub infrastructure) is getting a small verified data cap, the private key of the Developer will not be controlled or managed by Textile.

We will also work to provide documentation to developers on how to use external notaries. As new notaries come online capable of supporting the multisig configuration, we will detail how Developers can use those too.

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.

We have no miner affiliations or stake and we don't control any addresses that participate in miner activities. We manage ~10,000 addresses wallets addresses, all of which are used for client-side usage of the network, and we hold offline wallets. Most wallets on our infrastructure contain multiple addresses, here we've included the primary address from some of the most active wallets:

f122oundgemxqg72m3vot6bcllrrpsdyubt24ti5y, f13ejf7eoeso323jckln3qpgenscu24r46vat2jyq, f14t7eetamy7stgokuckxlv3vkpe52ahkq4mozsqy, f173v2ov3luv6rsdjsly3bkce43aw23xkdweftjfy, f1bh2swwy2attexmdtvd7pbdfpfnxrnzzszxpguli, f1dgn27wwdq4rjpbyj7xbuzk6vqtozumzbozs2w4i, f1hnkqmbx2a24szukguaxepee4quzryuzcwwvstjq, f1j2ex3wwv5f4t6dxiy6xpyylibljwo7ycuj2sbzy, f1kck2n6ayhwigctyjsrdaeaf6ojdwmmb6lm43tia, f1li5konrkmfyibmrcskhr7g3tqeyq43to6h5ahoy, f1mejl6qu7eshrmjbsdo3nsdefpyohp5now4yprii, f1mmyo2rvmrwm5ycv3527mab4az3waejdhugx3gwa, f1n4kuihubfesg55brkx5ntwqyglvbhydxjfodwra, f1oswyx7mp2djk3y7y3k6remrxpyhjsel7cw3bwmi, f1pprke3dauprojsyb3kqeadaewmklagu2pzqqb2a, f1qijmpzt2ykxhnenpjjks2ck2crj6ju4obqg7xna, f1r4upvqul7him3pxojhcvgrfzhuenx5noxasazfq, f1sssqd4gjt5i2cyxxnwhbargnrhdmuavq7fnvxla, f1tyvdpsxtz27n4nrexrreenl7savpxgqueumbsyq, f1uysropejhkkhvexsimnxk3wvtjo6ritild4vpvq, f1x643umdc4i7mtzpsqfwbpiet7mbnggvcsm6qxoa, f1xzzlcoea7iwilk7ef2zb4e7rgxsy2ax52f3lysq

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.

f2kb4izxsxu2jyyslzwmv2sfbrgpld56efedgru5i (f0103359)

[jnthnvctr]

Request Approved

Address

f2kb4izxsxu2jyyslzwmv2sfbrgpld56efedgru5i

Datacap Allocated

100TiB