Closed Xingchi-Media closed 1 year ago
f02049625
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
400% of weekly dc amount requested
800TiB
363797880709171380224.0YiB
363797880709171380224.0YiB
Number of deals | Number of storage providers | Previous DC Allocated | Top provider | Remaining DC |
---|---|---|---|---|
17448 | 5 | 400TiB | 54.5 | 61.78TiB |
Very happy to see that you are fixing the warning report, and have gotten the fix plan in the next round Will support this case
Your Datacap Allocation Request has been proposed by the Notary
bafy2bzacebc7owlhystahr5w4332zc67nagcslz6brkpitba72k4zsdenjudu
Address
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
Datacap Allocated
800.00TiB
Signer Address
f12tk3adljauwnd3hjbigpfxb7b7gdlj63p6afwtq
Id
4f681229-ba56-4856-9733-e5400e5a151d
You can check the status of the message here: https://filfox.info/en/message/bafy2bzacebc7owlhystahr5w4332zc67nagcslz6brkpitba72k4zsdenjudu
Considering the whole series have 10 addresses, the CID report looks OK to me.
Hello @Xingchi-Media , nice to see you again.
It seems issue 638 is also from you. We ended in #638 that you were storing something else then you said you were storing.
Can you explain why you created a whole new github account please for this LDN?
@kernelogic ... I am going to open an dispute on this application until clarification has been given.
Your Datacap Allocation Request has been approved by the Notary
bafy2bzaceahs6c2wufldgyvsj5i6i5wkrlruekkfo2ieiniskr3vw5oxxvfgm
Address
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
Datacap Allocated
800.00TiB
Signer Address
f1yjhnsoga2ccnepb7t3p3ov5fzom3syhsuinxexa
Id
4f681229-ba56-4856-9733-e5400e5a151d
You can check the status of the message here: https://filfox.info/en/message/bafy2bzaceahs6c2wufldgyvsj5i6i5wkrlruekkfo2ieiniskr3vw5oxxvfgm
checker:manualTrigger
⚠️ 1 storage providers sealed too much duplicate data - f02199166: 22.57%
✔️ Data replication looks healthy.
✔️ No CID sharing has been observed.
[^1]: To manually trigger this report, add a comment with text checker:manualTrigger
[^2]: Deals from those addresses are combined into this report as they are specified with checker:manualTrigger
[^3]: To manually trigger this report with deals from other related addresses, add a comment with text checker:manualTrigger <other_address_1> <other_address_2> ...
Click here to view the CID Checker report. Click here to view the Retrieval report.
Hi Sir @cryptowhizzard
**1. Participate in notary governance meetings;
We checked the records and the association you are referring to is "Wallet address #638 sent some Fil to wallet address #1059."
The reason for this, It was caused by the operation and maintenance personnel who provided us with technical services due to operational errors.
Because some SP cooperates with 638, and the operation and maintenance personnel of this SP are the same person as ours. After the cooperation with 638 ended, the operation and maintenance personnel did not clear the key of #638 from the server in time.
In April, because of #1059 need to reclaim DC quota. The operation and maintenance personnel checked the server where the secret key was stored and found that there were some tokens in 638's wallet, so they withdrew cash from there. This is the only relationship between the two LDNs. Other than that, there is no other connection.
In the past, because we were not clear about the Filplus rules, we had some non-compliance situations in #1059, but we have been learning and making progress. According to the latest CIDChecker report, our storage rules are all based on Fil+ rule execution of. We require all SPs we work with to save Unseal files and enable retrieval.
f02049625
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
800TiB
c0c36e7c-bc88-42ad-ac88-9949363521a3
f02049625
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
400% of weekly dc amount requested
800TiB
7.275957614183429e+35YiB
7.275957614183429e+35YiB
Number of deals | Number of storage providers | Previous DC Allocated | Top provider | Remaining DC |
---|---|---|---|---|
46437 | 8 | 800TiB | 29.51 | 0B |
Hi Sir @cryptowhizzard #638 has nothing to do with us, our company did multiple rounds of KYC before loading data into Filecoin. 1. Participate in notary governance meetings; 2. Passed the KYC review of Fil-E; 3. Provide private information such as the business license of the enterprise, the authorization letter of the enterprise legal person, and have been reviewed and certified by multiple notaries.
We checked the records and the association you are referring to is "Wallet address #638 sent some Fil to wallet address #1059."
The reason for this, It was caused by the operation and maintenance personnel who provided us with technical services due to operational errors.
Because some SP cooperates with 638, and the operation and maintenance personnel of this SP are the same person as ours. After the cooperation with 638 ended, the operation and maintenance personnel did not clear the key of #638 from the server in time.
In April, because of #1059 need to reclaim DC quota. The operation and maintenance personnel checked the server where the secret key was stored and found that there were some tokens in 638's wallet, so they withdrew cash from there. This is the only relationship between the two LDNs. Other than that, there is no other connection.
In the past, because we were not clear about the Filplus rules, we had some non-compliance situations in #1059, but we have been learning and making progress. According to the latest CIDChecker report, our storage rules are all based on Fil+ rule execution of. We require all SPs we work with to save Unseal files and enable retrieval.
Thank you for this explanation. We can put this to rest now and move on.
checker:manualTrigger
⚠️ 1 storage providers sealed too much duplicate data - f02199166: 22.57%
⚠️ 45.17% of deals are for data replicated across less than 4 storage providers.
✔️ No CID sharing has been observed.
[^1]: To manually trigger this report, add a comment with text checker:manualTrigger
[^2]: Deals from those addresses are combined into this report as they are specified with checker:manualTrigger
[^3]: To manually trigger this report with deals from other related addresses, add a comment with text checker:manualTrigger <other_address_1> <other_address_2> ...
Click here to view the CID Checker report. Click here to view the Retrieval report.
The client has provided an explanation for the doubts and will continue to improve the dispersion of data in the future. Move on.
Your Datacap Allocation Request has been proposed by the Notary
bafy2bzacecoesbxyujirknv7nvg3azuxet7nwytwjbivbrdu6qhtuubvn3slg
Address
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
Datacap Allocated
800.00TiB
Signer Address
f1tfg54zzscugttejv336vivknmsnzzmyudp3t7wi
Id
c0c36e7c-bc88-42ad-ac88-9949363521a3
You can check the status of the message here: https://filfox.info/en/message/bafy2bzacecoesbxyujirknv7nvg3azuxet7nwytwjbivbrdu6qhtuubvn3slg
Please make sure you distribute more copies of the same data in the next round.
Your Datacap Allocation Request has been approved by the Notary
bafy2bzacedscswussm2wxrftrtacsgy4qukdfnafafbyflutwjdrjdyagrraa
Address
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
Datacap Allocated
800.00TiB
Signer Address
f1a2lia2cwwekeubwo4nppt4v4vebxs2frozarz3q
Id
c0c36e7c-bc88-42ad-ac88-9949363521a3
You can check the status of the message here: https://filfox.info/en/message/bafy2bzacedscswussm2wxrftrtacsgy4qukdfnafafbyflutwjdrjdyagrraa
f02049625
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
800TiB
3ccbfd05-196c-4572-8182-445da013f2bd
f02049625
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
400% of weekly dc amount requested
800TiB
7.275957614183429e+35YiB
7.275957614183429e+35YiB
Number of deals | Number of storage providers | Previous DC Allocated | Top provider | Remaining DC |
---|---|---|---|---|
63731 | 10 | 800TiB | 28.09 | 223.59TiB |
checker:manualTrigger
⚠️ 1 storage providers sealed too much duplicate data - f02199166: 22.57%
⚠️ 38.20% of deals are for data replicated across less than 4 storage providers.
✔️ No CID sharing has been observed.
[^1]: To manually trigger this report, add a comment with text checker:manualTrigger
[^2]: Deals from those addresses are combined into this report as they are specified with checker:manualTrigger
[^3]: To manually trigger this report with deals from other related addresses, add a comment with text checker:manualTrigger <other_address_1> <other_address_2> ...
Click here to view the CID Checker report. Click here to view the Retrieval Dashboard. Click here to view the Retrieval report.
Dear Notary & T&T Sorry about the duplicate explanation: Because our technicians made mistakes, about 20T of data was repeatedly sent to f02199166. We are already aware of this problem, and we know that this is not compliant, and we will ensure that such errors will not occur again in the future.
Storage Provider Distribution ⚠️ 1 storage providers sealed too much duplicate data - f02199166: 22.57%
Regarding the distribution ratio, we will continue to adjust it in the next round. make it more dispersed
Deal Data Replication ⚠️ 38.20% of deals are for data replicated across less than 4 storage providers.
Looking forward to seeing the improvement in this round. Willing to support this E-FIL+ program.
Your Datacap Allocation Request has been proposed by the Notary
bafy2bzacea2beoz6sbtisxazcmghnsrwbgoi6gyu3b5s623pdcih7s2f6btri
Address
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
Datacap Allocated
800.00TiB
Signer Address
f1bp3tzp536edm7dodldceekzbsx7zcy7hdfg6uzq
Id
3ccbfd05-196c-4572-8182-445da013f2bd
You can check the status of the message here: https://filfox.info/en/message/bafy2bzacea2beoz6sbtisxazcmghnsrwbgoi6gyu3b5s623pdcih7s2f6btri
checker:manualTrigger
⚠️ 1 storage providers sealed too much duplicate data - f02199166: 22.57%
⚠️ 38.20% of deals are for data replicated across less than 4 storage providers.
✔️ No CID sharing has been observed.
[^1]: To manually trigger this report, add a comment with text checker:manualTrigger
[^2]: Deals from those addresses are combined into this report as they are specified with checker:manualTrigger
[^3]: To manually trigger this report with deals from other related addresses, add a comment with text checker:manualTrigger <other_address_1> <other_address_2> ...
Click here to view the CID Checker report. Click here to view the Retrieval Dashboard. Click here to view the Retrieval report.
Reached out by the client. Walked through CIDChecker warning again with the client.
Your Datacap Allocation Request has been approved by the Notary
bafy2bzaceabtchdw3csmd23jiw7qvtodhfalltqnzthzsv6arezvrbo7dkgys
Address
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
Datacap Allocated
800.00TiB
Signer Address
f1j3u7crhjzwb2cj5mq7vodlt4o66yoyci7lhcauy
Id
3ccbfd05-196c-4572-8182-445da013f2bd
You can check the status of the message here: https://filfox.info/en/message/bafy2bzaceabtchdw3csmd23jiw7qvtodhfalltqnzthzsv6arezvrbo7dkgys
f02049625
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
800TiB
9f17d40b-0d1d-4ad6-9c99-206d33e6a3d8
f02049625
f1vnfbc3siofrens2inl66gjzevqrto5wlsray6gy
400% of weekly dc amount requested
800TiB
7.275957614183433e+65YiB
7.275957614183433e+65YiB
Number of deals | Number of storage providers | Previous DC Allocated | Top provider | Remaining DC |
---|---|---|---|---|
79870 | 10 | 800TiB | 27.67 | 268.75TiB |
I have been trying to do some retrievals on this client but i only get errors.
cat 1051-f01982219-f02236251-47554415-baga6ea4seaqmvtxue43qa62hh5bv3hcddtf5zjsv6nxrvkkisnzit7bfzcntgai.log ERROR: offer error: retrieval query offer errored: failed to fetch piece to retrieve from: getting pieces for cid bafybeic5ckioxgnqlvai6sc4l6ghnjr7dz7jqpmipuyoeja6afrfia5kwi: getting pieces containing block bafybeic5ckioxgnqlvai6sc4l6ghnjr7dz7jqpmipuyoeja6afrfia5kwi: failed to lookup index for mh 12205d1290eb99b05d408f485c5f8c76a63f1e7e983d887d30e2241e01625403aab2, err: datastore: key not found
@Xingchi-Media
Can you make bafybeic5ckioxgnqlvai6sc4l6ghnjr7dz7jqpmipuyoeja6afrfia5kwi available for download? I want to see the contents of the file.
Thanks. Let me know when ready please.
Hey,Sir @cryptowhizzard After investigation and communication, we know the cause of the problem. Because the SP you retrieved is located in China and your location is in the Netherlands, there is no way to download it successfully.Because of the China Firewall, only the network in China can download data from this SP. SPs located in China, as long as they are not equipped with international networks, will have such problems.
@Xingchi-Media Hello friend, I am sorry but in your original allocation plan you wrote this:
Also, you stated that the data would be accessable to the whole world:
I am very sorry but your response "Because the SP you retrieved is located in China and your location is in the Netherlands, there is no way to download it" is simply invalid. Your data should be accessible and if this is not the case that is against the rules of FIL+.
Hey,Sir @cryptowhizzard After investigation and communication, we know the cause of the problem. Because the SP you retrieved is located in China and your location is in the Netherlands, there is no way to download it successfully.Because of the China Firewall, only the network in China can download data from this SP. SPs located in China, as long as they are not equipped with international networks, will have such problems.
This application should move to Fil-E then as it is not retrievable for everyone on the network. Please contact @kevzak.
Yes, Sir I think this is compliant and reasonable. Because it has something to do with the laws of each country, not that a certain SP maliciously does not support it.
If you want to obtain data and China cannot support it, you can retrieve data through SPs in other regions. This is the original intention and charm of Filecoin (decentralization). Data is not inaccessible due to a single point of reason.
Sir, There is a misunderstanding that this SP does not support anyone's retrieval, First, let's make a statement: This SP supports retrieval, It's just because of the national law and the restriction of the firewall, so the data cannot be downloaded in regions other than China. Of course, if you can contact the Chinese government to open the restrictions, You can download data from this SP here in any region.
Hey,Sir @cryptowhizzard After investigation and communication, we know the cause of the problem. Because the SP you retrieved is located in China and your location is in the Netherlands, there is no way to download it successfully.Because of the China Firewall, only the network in China can download data from this SP. SPs located in China, as long as they are not equipped with international networks, will have such problems.
This application should move to Fil-E then as it is not retrievable for everyone on the network. Please contact @kevzak.
Sir, There is a misunderstanding that this SP does not support anyone's retrieval, First, let's make a statement: This SP supports retrieval, It's just because of the national law and the restriction of the firewall, so the data cannot be downloaded in regions other than China. Of course, if you can contact the Chinese government to open the restrictions, You can download data from this SP here in any region.
Hey,Sir @cryptowhizzard After investigation and communication, we know the cause of the problem. Because the SP you retrieved is located in China and your location is in the Netherlands, there is no way to download it successfully.Because of the China Firewall, only the network in China can download data from this SP. SPs located in China, as long as they are not equipped with international networks, will have such problems.
This application should move to Fil-E then as it is not retrievable for everyone on the network. Please contact @kevzak.
Hi @Xingchi-Media
Please read the rules of Fil+. Your data needs to be accessible and redily retrievable by anyone on the network without restrictions. If this cannot be done the application should move to Fil-E for an exception.
Please check:
Great, Totally agree with the content of the screenshot you sent, And we have always asked for SP in this way.
@Xingchi-Media
Can you make bafybeic5ckioxgnqlvai6sc4l6ghnjr7dz7jqpmipuyoeja6afrfia5kwi available for download? I want to see the contents of the file.
SP told me they have done a repair rebuild and you can now manually retrieve it @cryptowhizzard
This application has not seen any responses in the last 10 days. This issue will be marked with Stale label and will be closed in 4 days. Comment if you want to keep this application open.
checker:manualTrigger
✔️ Storage provider distribution looks healthy.
⚠️ 34.81% of deals are for data replicated across less than 4 storage providers.
✔️ No CID sharing has been observed.
[^1]: To manually trigger this report, add a comment with text checker:manualTrigger
[^2]: Deals from those addresses are combined into this report as they are specified with checker:manualTrigger
[^3]: To manually trigger this report with deals from other related addresses, add a comment with text checker:manualTrigger <other_address_1> <other_address_2> ...
Click here to view the CID Checker report. Click here to view the Retrieval Dashboard. Click here to view the Retrieval report.
checker:manualTrigger
✔️ Storage provider distribution looks healthy.
⚠️ 34.81% of deals are for data replicated across less than 4 storage providers.
✔️ No CID sharing has been observed.
[^1]: To manually trigger this report, add a comment with text checker:manualTrigger
[^2]: Deals from those addresses are combined into this report as they are specified with checker:manualTrigger
[^3]: To manually trigger this report with deals from other related addresses, add a comment with text checker:manualTrigger <other_address_1> <other_address_2> ...
Click here to view the CID Checker report. Click here to view the Retrieval Dashboard. Click here to view the Retrieval report.
The retrieval rate is good, and the data distribution is also reasonable. Some of the data is only scattered across 3 SPs. The client has promised to make adjustments in the next round. Retrieval Statistics Overall Graphsync retrieval success rate: 46.54%
This LDN does not have CID sharing and is not on Dispute. So I am willing to support this round.
Large Dataset Notary Application
To apply for DataCap to onboard your dataset to Filecoin, please fill out the following.
Core Information
Please respond to the questions below by replacing the text saying "Please answer here". Include as much detail as you can in your answer.
Project details
Share a brief history of your project and organization.
What is the primary source of funding for this project?
What other projects/ecosystem stakeholders is this project associated with?
Use-case details
Describe the data being stored onto Filecoin
Where was the data in this dataset sourced from?
Can you share a sample of the data? A link to a file, an image, a table, etc., are good ways to do this.
Confirm that this is a public dataset that can be retrieved by anyone on the Network (i.e., no specific permissions or access rights are required to view the data).
What is the expected retrieval frequency for this data?
For how long do you plan to keep this dataset stored on Filecoin?
DataCap allocation plan
In which geographies (countries, regions) do you plan on making storage deals?
How will you be distributing your data to storage providers? Is there an offline data transfer process?
How do you plan on choosing the storage providers with whom you will be making deals? This should include a plan to ensure the data is retrievable in the future both by you and others.
How will you be distributing deals across storage providers?
Do you have the resources/funding to start making deals as soon as you receive DataCap? What support from the community would help you onboard onto Filecoin?