Notary Application Renewal: Textile

[carsonfarmer]

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.

Yes

See #53

Cumulatively, how much DataCap have you previously successfully allocated?

TBD

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

None

[galen-mcandrew]

Textile - Round 3 Notary Election Scorecard.pdf

[andrewxhill]

hey @galen-mcandrew could you let us know a bit more about what info you need? is that related to a specific question(s) in the app that I should focus on adding more detail to or something more general?

[galen-mcandrew]

Looks like you may be missing a section from the new template, regarding "Service level agreement" and engagement in program:

Service Level Agreement

Engagement in Program

How much time per week, on average, are you willing to dedicate to participating in the Fil+ program? This includes making DataCap allocations (direct and/or Large Datasets), comments on discussion/issues, attendance in governance calls, messages in Slack, etc.

Please answer here.

[Kevin-FF-USA]

Hi @andrewxhill Congratulations! Based on this Notary election cycle's final scoring, you/your organization has qualified to be a Fil+ Notary! You will be receiving your final scored rubric soon, along with the total allocation of Datacap based on rubric scoring.

In order to confirm your participation as a Notary in the Fil+ ecosystem, please respond to the following:

1. Please confirm that the region of operation for client applications you will focus on is North America.



2. Please confirm each of the following items below (you can do this by quoting each of the following bullets and 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.


   • Commitment to efficiently serving the Network: Notaries agree to serve as fiduciaries of the Network, striving to work towards bringing useful data onto Filecoin and improving the experience for clients to do so. Notaries should generally be able to respond to Client applications and updates within 3 days, and should be comfortable communicating with Clients and Notaries if an application needs to be redirected.


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


   • Community Governance Participation: How many hours you will participate in the program each week?

3. Please list any addresses you are affiliated with, and state 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. This is the address which you will use to sign messages on-chain to verify clients (through using a Ledger and the Fil+ Registry App). If you have an active (non-zero) DataCap grant from a previous election cycle, please provide a different address here.


[galen-mcandrew]

@carsonfarmer

Please fill out this form to move forwards with the ratification process: https://airtable.com/shrs55Lzbm1wJTIRw

[andrewxhill]

hey team, just spotting

If you have an active (non-zero) DataCap grant from a previous election cycle, please provide a different address here.


we'll have to get you a new address. we want to move away from the multisig approach since it added some admin. are we fine to use an address from off the shelf lotus (not using ledger or glif)? just wanted to make sure the notary app would work fine for login etc, couldn't recall the status of that.

[Kevin-FF-USA]

Hello @andrewxhill!

Just a friendly ping - There is some additional information needed in order to finalize, can you please follow this link to complete by April 15th?
Acceptance Form

[andrewxhill]

hey kevin, happy to. also see my question a comment previous.

[jsign]

Hello @andrewxhill!

Just a friendly ping - There is some additional information needed in order to finalize, can you please follow this link to complete by April 15th? Acceptance Form

@Kevin-FF-USA, actually we've already filled that form and submitted it. We used my name (Ignacio) for it.
In the Notary Address * section I filled f2kb4izxsxu2jyyslzwmv2sfbrgpld56efedgru5i since the description said This should match the address posted in your GitHub application., so I wanted to be coherent.

Maybe you want to dismiss this existing submission, and I can fill that form again with the newly decided address (Andrew's question). And later edit the first post of this issue with the right address to match the form field description match.

[galen-mcandrew]

The registry app at plus.fil.org currently only support ledger sign-in. So, you will not be able to generate an address natively in lotus.

Please let us know which ledger address you would like to use, and we can update our docs. You can then confirm that address using the verification tool in the Fil+ Registry app.

Here is a troubleshooting guide.

Thanks!

[galen-mcandrew]

Checking back in here on the status of your ledger address. @andrewxhill @carsonfarmer

Hoping to get the updated address and allocate the new amount of DataCap for direct notary requests (100TiB)