search

keyko-io / filecoin-notaries-onboarding

Filecoin Notaries on boarding
Apache License 2.0
0 stars 0 forks source link

Notary Request for: [Organization Name] #402

Closed fabriziogianni7 closed 2 years ago

fabriziogianni7 commented 2 years ago

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

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 https://github.com/filecoin-project/notary-governance/issues/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
fabriziogianni7 commented 2 years ago

Notary Ledger Verified

Message sent to Filecoin Network

message CID: bafy2bzacedyqtjxmsh5j5fcatpkvlyixepmcm5ekddxgllrnk43lxzovxpcls

You can check the status of the message here: https://filfox.info/en/message/bafy2bzacedyqtjxmsh5j5fcatpkvlyixepmcm5ekddxgllrnk43lxzovxpcls