Notary Application: Glif Verifier

[Schwartz10]

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: Jonathan Schwartz
• (Optional) Affiliated Organization: Infinite Scroll
• Website / Social Media: infinitescroll.org
• On-chain Address(es) to be Notarized: f3qhxw3qnxma2bc6ed5wh322sop3y5tvpzufu24szetytxezihaxs3pid4a5j6nsfqfxixmias3qv4bdk73whq
• Region of Operation: North America
• Use case(s) to be supported: Automatic Notary
• DataCap Requested: 100TiB

Please respond to the questions below in pargraph 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).

My team and I have worked closely with prominent members of the Filecoin community to deliver useful tools for the ecosystem. We’ve led and contributed to several projects in the Filecoin ecosystem, through [Glif](https://www.glif.io/) - a set of (open source, source available at https://github.com/glifio ) interoperable tools for the Filecoin network, which include: 

[Wallet](https://wallet.glif.io) - a web interface to send and receive FIL with a Ledger (https://github.com/glifio/wallet) 
[Vault](https://wallet.glif.io/vault) - managed FIL SAFT distribution
Managed Filecoin Nodes 

In addition to Glif, my team and I also managed the FIL Faucet (https://github.com/glifio/faucet) for the [Filecoin Space Race](https://spacerace.filecoin.io/). 

Stake Exposure

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

Prefer not to disclose. 

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.

My involvement in the Filecoin community started over a year ago, when I was exploring opportunities for a dev grant to build tooling for the Filecoin ecosystem. Since then, I have contributed several useful tools through [Glif](https://www.glif.io/), which have been critical to various stakeholders in the Filecoin ecosystem - this includes building the tool that enabled SAFT distribution for FIL purchased at ICO and managing the FIL Faucet for the Space Race (pre-mainnet). 

I’ve been an active participant in the development of lotus, working closely with the team at Protocol Labs to write software around it, and identify issues, [here](https://github.com/filecoin-project/lotus/issues?q=is%3Aissue+author%3ASchwartz10) are a few.

Lastly, my company has been involved in adjacent ecosystems for a while as well. For example, nearly two years ago we built an open source framework ([Quasar](https://github.com/infinitescroll/quasar)) for permissioning IPFS cluster’s via Ethereum smart contracts for the Aragon network. I also worked on an IPFS [dev grant](https://github.com/ipfs/devgrants/pull/18) for enabling the ipfs-http-client in React Native.

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.

Infinite Scroll (previously called Open Work Labs) is a US based software engineering and design studio, primarily focused on building web3 technologies with pleasurable experiences. We are four partners - all of us code, previously ran our own startups, and bring our own special set of expertise to the team. Our partners have worked with top crypto & web3 projects such as Aragon, Maker, Ethereum Foundation, Radicle, and 3Box.

Country of Registration: United States of America
Size of organization: 4 partners + sub contractors
Time since inception: 2 years

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

https://www.infinitescroll.org/
https://github.com/infinitescroll/

https://glif.io/ 
https://github.com/glifio/ 

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

Twitter: https://twitter.com/infinitescroll_/
Are.na: https://www.are.na/infinite-scroll/ 

Diversity and Decentralization

Use Case Diversity

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

By running an automated verifier that checks for GitHub based metadata as the basis for approval for DataCap, we are able to create a process that is completely unbiased and unprejudiced in how we select clients for DataCap. This will enable a wide variety of different clients to use Filecoin to store legitimate data, without having to go through a complex or subjective process.

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.

DataCap will be allocated through the Glif Verification website, hosted at https://verify.glif.io/. Potential clients can sign up for DataCap by connecting / logging into their GitHub account. The site checks if the GitHub account has been around for at least 180 days, and then allocates 8GB of DataCap to the linked address, at most once every 30 days. 

This enables easy testing and experimentation for Filecoin Storage use cases that no longer will have to go through a manually managed notary process.

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

DataCap will be allocated at 8GB per user that connects their GitHub account to the Verifier site. 

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

We will have our own dedicated Lotus node that is secured by Lotus’ native JWT model. We will not keep large amounts of FIL or verified data allowances on the node. Additionally, by the time the verifier is up and running on Mainnet, we will have removed any reliance on a specific Lotus node's wallet, and instead, allow all signing to happen externally - this increases security best practices and uptime.

Running the space-race faucet (another GitHub oauth protected webapp) provided our team with a lot of experience in recognizing vulnerabilities and defending against attacks. We’ve already dealt with and stopped DDOS attacks, scripted bot attacks, fake GitHub account creation, and other funny tricks to game the system. 

Client Due Diligence

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

The aim with this automatic service is to provide small amounts of DataCap freely to clients. Given the experience we had managing the Faucet during Space Race, we know this is a service that might be abused. As such we’re taking a number of steps (non-exhaustively listed here for security) in order to ensure this service is not abused. 

We require incoming clients to use a third-party OAuth service, with parameters we can tweak in order to constrict potential users to be highly likely “legitimate” users.
We rate limit the amount of DataCap allocatable to each authenticated user based on the total amount of time.
We keep the total allocation amount quite low, such that in the event someone does try to “game” the service, the risk is quite low. 
We plan on actively monitoring the in-bound requests initially to make adjustments based on potentially suspicious network activity. 

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

None. The process is completely automated.

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

Given the intent of this service is to enable small amounts of DataCap to individual users for testing, we do not take into account where the Client’s spend their DataCap.

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?

The only records we keep are mappings from GitHub ID to the most recent verified data grant. All other bookkeeping and records can be queried and found on-chain.

We do not link Filecoin addresses back to GitHub IDs for security and privacy reasons.

In the event that an invalid GitHub profile makes a request, we log information about that request to our private Slack channel.

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

Allocation decisions are made objectively against a set of predefined criteria mentioned above. These criteria will be mentioned in public at https://verify.glif.io. 

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 @Schwartz10 - based on your application, we've provided a scoring: #48

Eligibility Score: 2
Unrounded Score: 1.9

[jnthnvctr]

Hi @Schwartz10 - 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.

[Schwartz10]

1. Yes, we are in NA region

Upfront Disclosures

ACK.

Promoting Client Best Practices

ACK.

No Self Dealing

ACK.

Operating in good faith

ACK.

3. We do not have any affiliations with any mining operations. We will disclose all client addresses if/when we get any in the future.

4. ACK!

5. I'm actually going to give a new address f3qqlzlsjxgy67wdwe5ade5ygk7omp6cnze3nr3aoxwtptjg3ar4i3w26p4rplnm7ppeeyjlwtxqawx2boioma

[jnthnvctr]

Request Approved

Address

f3qqlzlsjxgy67wdwe5ade5ygk7omp6cnze3nr3aoxwtptjg3ar4i3w26p4rplnm7ppeeyjlwtxqawx2boioma

Datacap Allocated

100TiB

[dkkapur]

In line with #100 - this Notary will likely be updating their allocation strategy. This has been discussed at 2 previous governance calls and in general, the community is aligned.

@Schwartz10 can you confirm next steps on your end and timeline? Thanks!

[Schwartz10]

@dkkapur this should be in prod by EOD tomorrow.

[Schwartz10]

@dkkapur this has been pushed to prod. The allowance throttler has been dropped to 10, so if any scripted attacks occur, no more than 10 allocations will be granted without a manual button press on our end to reset it. We can slowly ease up the throttle as we gain confidence.