filecoin-project / Allocator-Governance

7 stars 32 forks source link

2nd Community Diligence Review of Meta Era Allocator #108

Open filecoin-watchdog opened 2 months ago

filecoin-watchdog commented 2 months ago

@cockroachboss Allocator report: https://compliance.allocator.tech/report/f03014641/1721400670/report.md

First diligence review: https://github.com/filecoin-project/Allocator-Governance/issues/19

SP retrievals still low on two public open dataset clients

CockroachBoss commented 1 month ago

Hi @filecoin-watchdog please check https://github.com/CockroachBoss/Allocator-MediaPlatformData/issues/4#issuecomment-2264450273 Most clients encounter this situation, which should serve as a warning. This situation exemplifies the “Single Standard Bias.” This bias occurs when an evaluation is based solely on one criterion, ignoring other relevant facts or standards, leading to the denial or misunderstanding of the facts. This can result in unfair assessments and decisions. I agree with this statement but feel helpless as well.

some of the nodes using boost can be shown the rate on the report

11

It seems that some of the nodes will need to wait for new tools to emerge or find other solutions. I hope you understand the situation, and we are also doing our best to monitor it. What do you think the next step should be?

CockroachBoss commented 1 month ago

Hello @filecoin-watchdog
Do you mind checking it out?

CockroachBoss commented 1 month ago

@filecoin-watchdog @Kevin-FF-USA Hi, Any updates here?

galen-mcandrew commented 3 weeks ago

This allocator is still primarily working with the same 2 clients, and those both claim to have public open data. While there is some evidence of intervention and diligence on the part of the allocator to these clients, the clients are still broadly non-compliant. For example, this report still shows non-compliant retrieval (despite claims of updates and additional retrieval methods) as well as non-compliant data distribution to SPs (regional, number, VPNs).

The primary client has incomplete initial application details (with multiple "No Response" answers). This client claims to be an SP preparing slingshot data, with a wide range of claimed data types but no explanation of data ownership or provenance.

The other client AOLIGEI has already been flagged in this ecosystem for showing up across various seemingly unrelated projects and noncompliance.

Beyond these issues, there is increasing evidence that this allocator is not making sufficient effort to enforce their own stated application targets and requirements. For example, question 10 listed only enterprise web3 clients as target clients, and neither of the above approved clients fit that category. There is also no evidence of utilizing 3rd party KYC services, or

Given the continued support of this kind of activity across a range of metrics (missing client info, lack of data ownership, poor SP distribution, insufficient retrieval, previously flagged data clients, etc), as well as the broad and unenforced nature of the initial allocator application, we are proposing removal of this allocator pathway.

This team can reapply under the new rolling application with a more scoped and specific set of requirements, such as a more narrow set of allowed client and data types.

CockroachBoss commented 2 weeks ago

Hello @galen-mcandrew

Thank you for sharing your detailed feedback. I genuinely appreciate it, as it helps me better understand your evaluation criteria. However, I believe it would have been even more beneficial if such concerns had been raised earlier, enabling me to more effectively adhere to my role as someone who is officially entrusted with review authority.

Below are my responses to some of the points you’ve raised:

This allocator is still primarily working with the same 2 clients, and those both claim to have public open data.

The reason I have only two clients at the moment is that the quota allocated to me is relatively small. Given this limited quota, I haven’t actively pushed potential clients (such as certain web3 media institutions) to start data collaborations. However, we have discussed this, and they have expressed interest. My approach is to maintain long-term relationships with clients who show loyalty and to observe their progress with each iteration.

While there is some evidence of intervention and diligence on the part of the allocator to these clients, the clients are still broadly non-compliant. For example, this report still shows non-compliant retrieval (despite claims of updates and additional retrieval methods) as well as non-compliant data distribution to SPs (regional, number, VPNs).

I appreciate that you recognized my efforts in due diligence. Especially after the first allocator review, I realized the need to disclose KYB results, so I conducted additional disclosures for both clients. I have also been working to assist them with the challenges they face. The report you referred to is an outdated version. Here is the report you mentioned: (https://check.allocator.tech/report/CockroachBoss/Allocator-MediaPlatformData/issues/4/1725863681824.md. ) This report reflects the results after the client contacted new SPs and those SPs changed their packaging methods to comply with the Spark tool. As you can see, the client contacted me more than once, but I refused to sign for them initially as they didn’t provide a specific list of SPs. It wasn’t until a month later, when they provided the new SP list, that I signed off. The results show they fulfilled their commitment.

The primary https://github.com/CockroachBoss/Allocator-MediaPlatformData/issues/4 has incomplete initial application details (with multiple "No Response" answers). This client claims to be an SP preparing slingshot data, with a wide range of claimed data types but no explanation of data ownership or provenance. The other https://github.com/CockroachBoss/Allocator-MediaPlatformData/issues/2 AOLIGEI has already been flagged in this ecosystem for showing up across various seemingly unrelated projects and noncompliance.

Regarding this, I have reviewed their past application records via this link: https://datacapstats.io/clients?filter=aoligei, and didn’t see any significant issues, nor any flagged status. Secondly, I wasn’t a notary before becoming an allocator, so I believe it is unnecessary for allocators like me to fully understand clients’ past activities. However, if there are flagged clients, it would be beneficial to have a link where we can mark them. I suggest promoting this within the community.

Beyond these issues, there is increasing evidence that this allocator is not making sufficient effort to enforce their own stated application targets and requirements. For example, question 10 listed only enterprise web3 clients as target clients, and neither of the above approved clients fit that category.

-Hetpa is a web3 client engaged in decentralized infrastructure services from Korea. They sent me their business license via email, which I believe is genuine. -AOLIGEI is a media company, and their business information can be verified on Chinese websites. These clients fall under the target categories I’ve outlined.

There is also no evidence of utilizing 3rd party KYC services.

To be honest, I cannot afford to pay for third-party services as I do not make any money from this role.

In conclusion:

•   I fully understand Hetpa’s situation and have conducted extensive due diligence. The current results indicate that they have indeed met their commitments. Please note that the report you referenced is not the latest version.
•   Regarding AOLIGEI, despite multiple inquiries, they have not responded, and I have not signed off for them. My original intent was to close their issue if they remained unresponsive by the end of my review period.

To address your concerns, I will perform further data source screening for our clients in the future. I also plan to reach out to web3 media peers to introduce them to the FIL+ program.

Therefore, I kindly ask that you reconsider your proposal, or allow me to continue under the same amount. Thank you for your understanding and time.

galen-mcandrew commented 4 days ago

@CockroachBoss

We have reviewed the information provided here, and we will request an additional 2.5PiB of DataCap. I strongly encourage you to review you allocator application, and make extra effort to provide evidence of diligence and compliance with all the requirements.