Community Review of IPFSCN

[ipfscn]

Allocator Application：filecoin-project/notary-governance#1086
Allocator Compliance Report: https://compliance.allocator.tech/report/f03019942/1727049639/report.md

1. https://github.com/filplus-bookkeeping/IPFSCN/issues/21（1.75PiB)
   Enterprise data, sent to email for identity verification.
   The disclosure of SP is consistent with the actual cooperation SP.
   All SPs support retrieval, with an average Spark Retrieval Success Rate of 55%.
   

2. https://github.com/filplus-bookkeeping/IPFSCN/issues/15（1PiB)
   Public data
   All SPs support Spark, with an average Spark Retrieval Success Rate of 40%
   In the first round of signing, there was an operational error and 1 iB was released
   I have repeatedly requested the official to revoke the signature.
   
   

3. https://github.com/filplus-bookkeeping/IPFSCN/issues/7（2.2PiB）
   Public data
   This is the earliest LDN application, and some SPs use Venus and DDO, with an average Spark Retrieval Success Rate of 20%
   We will no longer sign for this client
   

[filecoin-watchdog]

Allocator Application
Compliance Report

https://github.com/filplus-bookkeeping/IPFSCN/issues/21
Retrieval rate could be better. All of the SPs have retrieval <75%.

filplus-bookkeeping/IPFSCN#15
The client asked for 5 PiB DC and probably mistakenly said the single dataset would be 7 PiB.
No answer to the data preparation method. The allocator should have followed up.

SPs list provided:
f02838518 Moscow, Moscow, RU -
f02832475 Bangkok, Bangkok, TH -
f02859053 Hanover, New Jersey, US -
f02826253 SINGAPORE
f02826815 HK
f03151449 SHENZHEN
f03151456 SHENZHEN

Actual SPs used for deals:
F03179570 SG
F03151449 CN
F03151456 CN
F02828269 CN
F02826253 SG
F02826815 HK
F02825282 HK

Only 4 SPs match the provided list. Did the allocator knew about SPs list change? Was the change justified?

filplus-bookkeeping/IPFSCN#7
No answer to the data preparation method. The allocator should have followed up.
Low retrieval rate across SPs. Only 4 Sps has retrieval rate higher than 0%.

[ipfscn]

Our 2.2P allocation was an early allocation when Spark had not yet been launched, so we collaborated with customers who used Venus and DDoS. Since Spark emerged, we have been demanding that all customers support Spark 100%, so we refused the SP for Venus and DDoS. Therefore, in the early stage where the retrieval rate of 2.2P was very low, due to our requirement that all SPs support Spark in the later stage, the retrieval rate of IPFSCN was 40.35%, and our goal is to achieve 50% Next, we will continue to strengthen support for SP for Spark. At the same time, we will also pay attention to customers' data preparation, data segmentation and other data solutions.

[galen-mcandrew]

Based on the investigation and details provided, we are seeing mixed compliance results. Some areas for this allocator to focus on should include:

• Data prep details from clients
• SP lists before and after allocations, with explanations from clients when there are changes made
• Continuing to improve retrieval rates

Given this review, we are requesting that the allocator verify that they will uphold all aspects & requirements of their initial application, with some extra focus on these areas. If so, we will request an additional 5PiB of DataCap from RKH, to allow this allocator to show increased diligence and alignment.

[ipfscn]

@galen-mcandrew Thank you. We will summarize past experiences and lessons learned to enhance our compliance performance, particularly in the key areas identified in this report.

[Kevin-FF-USA]

DataCap has been refilled.
https://datacapstats.io/notaries/f03019942