2nd Community Diligence Review of ByteBase (Destore) Allocator

[Destore2023]

This ronud we have allocated to four clients.
Destore2023/MetaPathways-Bookkeeping#6
Destore2023/MetaPathways-Bookkeeping#8
Destore2023/MetaPathways-Bookkeeping#13
Destore2023/MetaPathways-Bookkeeping#16

These clients are currently in process. Before allocation, we did due diligence on them - using a self-designed questionnaire to collect clients' information.

We ask our clients to provide the latest SP list regularly as a way to verify whether the SP supports retrieval or not. Current clients are actively cooperating with it. Please refer below links for detail.

1. SP list
   [DataCap Application] EOT Web Archive Dataset Destore2023/MetaPathways-Bookkeeping#6 (comment)
   Retrieval
   https://check.allocator.tech/report/Destore2023/MetaPathways-Bookkeeping/issues/6/1725274025457.md

2. SP list
   [DataCap Application] NIH NCBI SRA on AWS Destore2023/MetaPathways-Bookkeeping#8 (comment)
   Retrieval
   https://check.allocator.tech/report/Destore2023/MetaPathways-Bookkeeping/issues/8/1725274026727.md

3.SP list
Destore2023/MetaPathways-Bookkeeping#16 (comment)
Retrieval (no report)
Destore2023/MetaPathways-Bookkeeping#16 (comment)

We will stop working with clients who do not meet our standards. We required our clients to distribute data to at least four SPs.
Destore2023/MetaPathways-Bookkeeping#13

We will keep our process up-to-date and provide feedback on github repo. We will make our work more detailed and better. Hope to get a new round of 10P DataCap for further work.

[filecoin-watchdog]

Allocator compliance Report
First review
Allocator Application
2nd allocation date: 2024/08/07

Example 1
Even though 4/9 SPs have a high retrieval rate, 5/9 has 0 or below 75%. Has the Allocator contacted their client to explain the low retrievability for those SPs?

The majority of SPs are located in the same region.

SPs declared in the application:
f01841131 HONGKONG
f02244750 LONDON
f01807908 MADRID
f01879772 HONGKONG
f02363999 SINGAPORE

The client has updated their SPs after the first two allocations to be:
f03089385 New York
f03090976 Virginia
f03089826 Virginia
f03106356 Virginia

No explanation was made on the GitHub issue. Has the allocator made sure it was a legitimate change?

Example 2
The client said they wanted 1PiB of data. According to the Allocator application, they would send the first tranche at 25% of the total DC. Why is the Allocator granted 1PiB in the first and only tranche?

Example 3
The client has declared that there will be 10 data replicas. Is it clear why so many replicas are needed?
No CID checker is possible to generate for this client. How will the Allocator make sure the retrieval rate is on an acceptable level?

[Destore2023]

Hello @filecoin-watchdog, thanks for the review.

Example1

https://grafana.filstation.app/d/fea90509-20e8-4d49-b4ad-f0436da9c75d/spark-public-dashboard?orgId=1&from=now-6h&to=now&viewPanel=10

Here's their latest retrieval report on spark.

I have asked the client about their problems of retrieval. They said that some nodes (such as f03089385) have broken down and they would not continue chooes them any more. I understand the client's motive to change the sp, because I've reminded clients to replace sp that do not meet the require.

Example2
We had a face to face meeting with this customer and their SP.

At that time, we thought the client was more truthful and qualified for storage, but also with experienced SP, their SP also promised with good CID distribute and data retrieve ratio, based on this information, we assigned 1P datacap to the client as an experiment in this round.

We keep communication during the data onboarding, and you can also refer to the 2 times datacap-bot report for details. the SPARK result is also increasing.
2024/9/18 report

2024/9/27 report

Example3

https://check.allocator.tech/report/Destore2023/MetaPathways-Bookkeeping/issues/16/1727346611052.md

Here's their cid checker report.

We thought 10 replicas met the goal of distributed storage, and our standard is that clients need to store at least 5 or more replicas.

With an ongoing commitment to building a high-quality allocator pathway, we will build on our experience from each round of allocation practices to make our work more reflective of serving the community. As we hope that the help we provide to our clients enables more valuable data to be stored safely around the world. Also decentralized storage can be realized to develope!

[galen-mcandrew]

Overall strong diligence from this pathway. We would like to see some increased focus on the following areas:

• Verifying public client application details in GitHub, and providing diligence evidence for future bookkeeping investigations
• SP lists before and after allocations, with explanations from clients when there are changes made
• Increased investigation into SP regions and distribution, especially when VPNs are utilized
• Continuing to improve retrieval rates

Given the diligence evidence and retrieval we are seeing, we are requesting an additional 10 PiB of DataCap from RKH to support this allocator increasing their compliance and alignment.

[Destore2023]

Thanks Galen,

Overall strong diligence from this pathway. We would like to see some increased focus on the following areas:

• Verifying public client application details in GitHub, and providing diligence evidence for future bookkeeping investigations
• SP lists before and after allocations, with explanations from clients when there are changes made
• Increased investigation into SP regions and distribution, especially when VPNs are utilized
• Continuing to improve retrieval rates

Given the diligence evidence and retrieval we are seeing, we are requesting an additional 10 PiB of DataCap from RKH to support this allocator increasing their compliance and alignment.

Thank you @galen-mcandrew for your recognition and support. I will continue to work to serve our community

[Kevin-FF-USA]

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