[DataCap Application] Mianmian (Shanghai) Intelligent Technology Co., Ltd. - Sleep EEG Analyzing

[MianmianSH]

Large Dataset Notary Application

To apply for DataCap to onboard your dataset to Filecoin, please fill out the following.

Core Information

• Organization Name:Mianmian (Shanghai) Intelligent Technology Co., Ltd.
• Website / Social Media:www.mirahome.com
• Total amount of DataCap being requested (between 500 TiB and 5 PiB):3.5PiB
• Weekly allocation of DataCap requested (usually between 1-100TiB):80TiB
• On-chain address for first allocation:f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

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.

Mianmian is an innovative technology company focusing on the development of sleep detection and analysis, and the realization of intelligent products related to sleep improvement.
For the analysis of sleep EEG open data and Matlab code, the original Matlab files have been converted to EDF and merged. In this way, the EEG data of the human brain during sleep can be analyzed to explore the external factors affecting sleep quality. The resulting data will be used to adjust product parameters, such as the shape, material and elasticity, to create better products for improving sleep. They are expertly tailored to ensure maximum comfort in any and all sleeping positions.

What is the primary source of funding for this project?

Corporate financing and product sales collection.

What other projects/ecosystem stakeholders is this project associated with?

NO other stakeholder. We will seek out other Filecoin ecosystem providers if needed.

Use-case details

Describe the data being stored onto Filecoin

This provided EEG recordings (each comprising 58 EEG channels) on two individuals, for both N2 and N3 sleep, using two referencing schemes: linked mastoids, and the common average. The original 18 (i.e. 3 x 2 x 3) datasets are distributed in Matlab/EEGLAB format. 

Where was the data in this dataset sourced from?

It is derived from the clinical data of volunteers jointly collected by our company and relevant medical research laboratories. The data is true and effective and open to the public. The permission of relevant data has been obtained from the volunteers themselves.

Can you share a sample of the data? A link to a file, an image, a table, etc., are good ways to do this.

https://drive.google.com/drive/folders/1P3JePaGnuiG7BO4U4KsoO0NIQ3i8I_WN?usp=sharing

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).

Yes, it is a public data.

What is the expected retrieval frequency for this data?

The data is mainly used for scientific and academic research. It is available for download worldwide. However, the frequency of retrieval is not expected to be too high, as the use of this data requires a professional analysis ability in this subdivision. The frequency of download is expected to be around 50 times per year.

For how long do you plan to keep this dataset stored on Filecoin?

This data has long-term scientific value and we will store this data permanently.

DataCap allocation plan

In which geographies (countries, regions) do you plan on making storage deals?

East Asia and all regions in Southeast Asia.

How will you be distributing your data to storage providers? Is there an offline data transfer process?

Depending on the location of the storage provider, both online and offline modes are used.Online, we upload data to the cloud storage provider's server and send download URL to each other. Offline, we will send physical storage devices by express.
There are offline data transmission modes, which can be selected based on the distance.

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.

We select SP based on their price, operation team size, hardware equipment size, and energy security considerations to ensure the openness and reliability of data storage.

How will you be distributing deals across storage providers?

Based on the cost of data transfer with storage providers as a factor in data volume allocation, low-cost data transfer and high reliability of storage providers will result in a larger proportion of data volume. But we will always stick to decentralized storage, so that is a way of insurance.

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?

We have set aside sufficient funds for the work, and we can start the transaction immediately after obtaining the approval. I benefited from videos on Filecoin's official Slack channel and Bilibili.

[large-datacap-requests[bot]]

Stats & Info for DataCap Allocation

Multisig Notary address

f01858410

Client address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Last two approvers

fireflyHZ & BlockMakeronline

Rule to calculate the allocation request amount

800% of weekly dc amount requested

DataCap allocation requested

640TiB

Total DataCap granted for client so far

280TiB

Datacap to be granted to reach the total amount requested by the client (3.5PiB)

3.22PiB

Stats

Number of deals	Number of storage providers	Previous DC Allocated	Top provider	Remaining DC
6134	5	320TiB	47.39	71.93TiB

[filplus-checker-app[bot]]

DataCap and CID Checker Report[^1]

• Organization: Mianmian(Shanghai) Intelligent Technology Co., Ltd.
• Client: f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

  Storage Provider Distribution

  The below table shows the distribution of storage providers that have stored data for this client.

If this is the first time a provider takes verified deal, it will be marked as new.

For most of the datacap application, below restrictions should apply.

• Storage provider should not exceed 30% of total datacap.
• Storage provider should not be storing duplicate data for more than 20%.
• Storage provider should have published its public IP address.
• All storage providers should be located in different regions.

⚠️ f01981603 has sealed 50.10% of total datacap.

⚠️ f01981603 has unknown IP location.

⚠️ 25.98% of total deal sealed by f01964215 are duplicate data.

⚠️ f01964215 has unknown IP location.

⚠️ 63.69% of total deal sealed by f01959805 are duplicate data.

⚠️ f01959805 has unknown IP location.

⚠️ f01964253 has unknown IP location.

Provider	Location	Total Deals Sealed	Percentage	Unique Data	Duplicate Deals
f01981603	Unknown	87.22 TiB	50.10%	72.25 TiB	17.16%
f01964215	Unknown	47.63 TiB	27.36%	35.25 TiB	25.98%
f01959805	Unknown	19.97 TiB	11.47%	7.25 TiB	63.69%
f01986203new	Guangzhou, Guangdong, CN	10.16 TiB	5.83%	10.16 TiB	0.00%
f01964253	Unknown	9.13 TiB	5.24%	9.13 TiB	0.00%

Deal Data Replication

The below table shows how each many unique data are replicated across storage providers.

• No more than 30% of unique data are stored with less than 4 providers.

⚠️ 100.00% of deals are for data replicated across less than 4 storage providers.

Unique Data Size	Total Deals Made	Number of Providers	Deal Percentage
105.00 TiB	119.97 TiB	1	68.91%
9.69 TiB	44.47 TiB	2	25.54%
3.22 TiB	9.66 TiB	3	5.55%

Deal Data Shared with other Clients

The below table shows how many unique data are shared with other clients. Usually different applications owns different data and should not resolve to the same CID.

✔️ No CID sharing has been observed.

[^1]: To manually trigger this report, add a comment with text checker:manualTrigger

[Alex11801]

Request Proposed

Your Datacap Allocation Request has been proposed by the Notary

Message sent to Filecoin Network

bafy2bzaceaz5dhv2oquesikvwme2rydtn4et6gu73shoex6betfwt6jrvqo3o

Address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Datacap Allocated

640.00TiB

Signer Address

f1hhippi64yiyhpjdtbidfyzma6irc2nuav7mrwmi

Id

1c67627f-49e0-4625-8b55-780459b5e2f1

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

[psh0691]

Request Approved

Your Datacap Allocation Request has been approved by the Notary

Message sent to Filecoin Network

bafy2bzaceatlhmjmkcc3tvgpfsafhqibxugletwq377ott7rxyonddvgutsp4

Address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Datacap Allocated

640.00TiB

Signer Address

f1qdko4jg25vo35qmyvcrw4ak4fmuu3f5rif2kc7i

Id

1c67627f-49e0-4625-8b55-780459b5e2f1

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

[herrehesse]

May i ask why @psh0691 & @Alex11801 approve this datacap while there are a lot of questions coming from the CID report?

Example: ⚠️ f01981603 has sealed 50.10% of total datacap. ⚠️ f01981603 has unknown IP location.

[large-datacap-requests[bot]]

DataCap Allocation requested

Request number 6

Multisig Notary address

f01858410

Client address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

DataCap allocation requested

640TiB

Id

f956f6a4-a8ba-4a5d-a5ce-cf1b0a242965

[large-datacap-requests[bot]]

Stats & Info for DataCap Allocation

Multisig Notary address

f01858410

Client address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Last two approvers

psh0691 & Alex11801

Rule to calculate the allocation request amount

800% of weekly dc amount requested

DataCap allocation requested

640TiB

Total DataCap granted for client so far

600TiB

Datacap to be granted to reach the total amount requested by the client (3.5PiB)

2.91PiB

Stats

Number of deals	Number of storage providers	Previous DC Allocated	Top provider	Remaining DC
19200	5	640TiB	71.74	0B

[filplus-checker-app[bot]]

DataCap and CID Checker Report[^1]

• Organization: Mianmian(Shanghai) Intelligent Technology Co., Ltd.
• Client: f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

  Approvers

  1Alex11801
  1BlockMakeronline
  1IreneYoung
  1NDLABS-OFFICE
  1PluskitOfficial
  2psh0691
  1steven004
  1Tom-OriginStorage
  1YuanHeHK

Storage Provider Distribution

The below table shows the distribution of storage providers that have stored data for this client.

If this is the first time a provider takes verified deal, it will be marked as new.

For most of the datacap application, below restrictions should apply.

• Storage provider should not exceed 30% of total datacap.
• Storage provider should not be storing duplicate data for more than 20%.
• Storage provider should have published its public IP address.
• All storage providers should be located in different regions.

⚠️ 63.69% of total deal sealed by f01959805 are duplicate data.

⚠️ f01964215 has sealed 69.56% of total datacap.

⚠️ 72.07% of total deal sealed by f01964215 are duplicate data.

⚠️ 28.35% of total deal sealed by f01981603 are duplicate data.

Provider	Location	Total Deals Sealed	Percentage	Unique Data	Duplicate Deals
f01959805	Guangzhou, Guangdong, CN CHINANET Guangdong province network	19.97 TiB	3.74%	7.25 TiB	63.69%
f01964253	Guangzhou, Guangdong, CN CHINANET Guangdong province network	18.63 TiB	3.49%	18.63 TiB	0.00%
f01986203new	Guangzhou, Guangdong, CN CHINANET Guangdong province network	18.53 TiB	3.47%	18.53 TiB	0.00%
f01964215	Shenzhen, Guangdong, CN CHINANET-BACKBONE	371.19 TiB	69.56%	103.66 TiB	72.07%
f01981603	Hong Kong, Central and Western, HK HONG KONG BRIDGE INFO-TECH LIMITED	105.28 TiB	19.73%	75.44 TiB	28.35%

Deal Data Replication

The below table shows how each many unique data are replicated across storage providers.

• No more than 30% of unique data are stored with less than 4 providers.

⚠️ 100.00% of deals are for data replicated across less than 4 storage providers.

Unique Data Size	Total Deals Made	Number of Providers	Deal Percentage
147.13 TiB	354.38 TiB	1	66.41%
19.53 TiB	97.50 TiB	2	18.27%
12.44 TiB	81.72 TiB	3	15.31%

Deal Data Shared with other Clients

The below table shows how many unique data are shared with other clients. Usually different applications owns different data and should not resolve to the same CID.

However, this could be possible if all below clients use same software to prepare for the exact same dataset or they belong to a series of LDN applications for the same dataset.

✔️ No CID sharing has been observed.

[^1]: To manually trigger this report, add a comment with text checker:manualTrigger

[filplus-checker-app[bot]]

DataCap and CID Checker Report[^1]

• Organization: Mianmian(Shanghai) Intelligent Technology Co., Ltd.
• Client: f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

  Approvers

  1Alex11801
  1BlockMakeronline
  1IreneYoung
  1NDLABS-OFFICE
  1PluskitOfficial
  2psh0691
  1steven004
  1Tom-OriginStorage
  1YuanHeHK

Storage Provider Distribution

The below table shows the distribution of storage providers that have stored data for this client.

If this is the first time a provider takes verified deal, it will be marked as new.

For most of the datacap application, below restrictions should apply.

• Storage provider should not exceed 30% of total datacap.
• Storage provider should not be storing duplicate data for more than 20%.
• Storage provider should have published its public IP address.
• All storage providers should be located in different regions.

⚠️ 63.69% of total deal sealed by f01959805 are duplicate data.

⚠️ f01964215 has sealed 69.56% of total datacap.

⚠️ 72.07% of total deal sealed by f01964215 are duplicate data.

⚠️ 28.35% of total deal sealed by f01981603 are duplicate data.

Provider	Location	Total Deals Sealed	Percentage	Unique Data	Duplicate Deals
f01959805	Guangzhou, Guangdong, CN CHINANET Guangdong province network	19.97 TiB	3.74%	7.25 TiB	63.69%
f01964253	Guangzhou, Guangdong, CN CHINANET Guangdong province network	18.63 TiB	3.49%	18.63 TiB	0.00%
f01986203new	Guangzhou, Guangdong, CN CHINANET Guangdong province network	18.53 TiB	3.47%	18.53 TiB	0.00%
f01964215	Shenzhen, Guangdong, CN CHINANET-BACKBONE	371.19 TiB	69.56%	103.66 TiB	72.07%
f01981603	Hong Kong, Central and Western, HK HONG KONG BRIDGE INFO-TECH LIMITED	105.28 TiB	19.73%	75.44 TiB	28.35%

Deal Data Replication

The below table shows how each many unique data are replicated across storage providers.

• No more than 30% of unique data are stored with less than 4 providers.

⚠️ 100.00% of deals are for data replicated across less than 4 storage providers.

Unique Data Size	Total Deals Made	Number of Providers	Deal Percentage
147.13 TiB	354.38 TiB	1	66.41%
19.53 TiB	97.50 TiB	2	18.27%
12.44 TiB	81.72 TiB	3	15.31%

Deal Data Shared with other Clients

The below table shows how many unique data are shared with other clients. Usually different applications owns different data and should not resolve to the same CID.

However, this could be possible if all below clients use same software to prepare for the exact same dataset or they belong to a series of LDN applications for the same dataset.

✔️ No CID sharing has been observed.

[^1]: To manually trigger this report, add a comment with text checker:manualTrigger

[MianmianSH]

@herrehesse Since the filplus-checker program has not appeared before, we have some problems in the previous packaging process, I am sorry for that! This time I communicated with the above two notaries @psh0691 & @Alex11801 , and promised them that they will gradually fix the previous problems in the next DC quota package, including the problems of high repetition and IP disclosure. After the package of this batch is completed, many problems will be resolved and fixed, thanks a lot to the two notaries for the opportunity to fix the error. In the future, the report information of filplus-checker will be continuously synchronized.

[herrehesse]

@MianmianSH this is clearly unacceptable moving forward. Please help me answer the following questions:

Due to the increased amount of erroneous/wrong Filecoin+ data recently, on behalf of the entire community, we feel compelled to go deeper into datacap requests. Hereby to ensure that the overall value of the Filecoin network and Filecoin+ program increases and is not abused.

Please answer the questions below as comprehensively as possible.

Customer data

• Could you demonstrate exactly how and to what extent customer contact occurred?

We expect that for the onboarding of customers with the scale of an LDN there would have been at least multiple email and perhaps several chat conversations preceding it. A single email with an agreement does not qualify here.

• Did the customer specify the amount of data involved in this relevant correspondence?

• Why does the customer in question want to use the Filecoin+ program?

Should this only be soley for acquiring datacap this is of course out of the question. The customer must have a legitimate reason for wanting to use the Filecoin+ program which is intended as a program to store useful and public datasets on the network.

• Why is the customer data considered Filecoin+ eligible?

(As an intermediate solution Filecoin offers the FIL-E program or the glif.io website for business datasets that do not meet the requirements for a Filecoin+ dataset)

Files and Processing

• Could you please demonstrate to us how you envision processing and transporting the customer data in question to any location for preparation?
• Would you demonstrate to us that the customer, the preparer and the intended storage providers all have adequate bandwidth to process the set with its corresponding size?
• Would you tell us how the data set preparer takes into account the prevention of duplicates in order to prevent data cap abuse?

Hopefully you understand the caution the overall community has for onboarding the wrong data. We understand the increased need for Filecoin+, however, we must not allow the program to be misused. Everything depends on a valuable and useful network, let's do our best to make this happen. Together.

[MianmianSH]

checker:manualTrigger

[filplus-checker-app[bot]]

DataCap and CID Checker Report[^1]

• Organization: Mianmian(Shanghai) Intelligent Technology Co., Ltd.
• Client: f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

  Approvers

  1Alex11801
  1BlockMakeronline
  1IreneYoung
  1NDLABS-OFFICE
  1PluskitOfficial
  2psh0691
  1steven004
  1Tom-OriginStorage
  1YuanHeHK

Storage Provider Distribution

The below table shows the distribution of storage providers that have stored data for this client.

If this is the first time a provider takes verified deal, it will be marked as new.

For most of the datacap application, below restrictions should apply.

• Storage provider should not exceed 30% of total datacap.
• Storage provider should not be storing duplicate data for more than 20%.
• Storage provider should have published its public IP address.
• All storage providers should be located in different regions.

⚠️ 63.69% of total deal sealed by f01959805 are duplicate data.

⚠️ f01964215 has sealed 57.16% of total datacap.

⚠️ 72.07% of total deal sealed by f01964215 are duplicate data.

⚠️ 28.35% of total deal sealed by f01981603 are duplicate data.

Provider	Location	Total Deals Sealed	Percentage	Unique Data	Duplicate Deals
f01959805	Guangzhou, Guangdong, CN China Mobile communications corporation	19.97 TiB	3.08%	7.25 TiB	63.69%
f01964253	Guangzhou, Guangdong, CN China Mobile communications corporation	18.63 TiB	2.87%	18.63 TiB	0.00%
f01986203new	Guangzhou, Guangdong, CN China Mobile communications corporation	18.53 TiB	2.85%	18.53 TiB	0.00%
f01771695	Wuhan, Hubei, CN CHINA UNICOM China169 Backbone	115.78 TiB	17.83%	94.22 TiB	18.62%
f01964215	Shenzhen, Guangdong, CN CHINANET-BACKBONE	371.19 TiB	57.16%	103.66 TiB	72.07%
f01981603	Hong Kong, Central and Western, HK HONG KONG BRIDGE INFO-TECH LIMITED	105.28 TiB	16.21%	75.44 TiB	28.35%

Deal Data Replication

The below table shows how each many unique data are replicated across storage providers.

• No more than 30% of unique data are stored with less than 4 providers.

⚠️ 100.00% of deals are for data replicated across less than 4 storage providers.

Unique Data Size	Total Deals Made	Number of Providers	Deal Percentage
98.72 TiB	282.22 TiB	1	43.46%
90.84 TiB	285.44 TiB	2	43.96%
12.44 TiB	81.72 TiB	3	12.58%

Deal Data Shared with other Clients

The below table shows how many unique data are shared with other clients. Usually different applications owns different data and should not resolve to the same CID.

However, this could be possible if all below clients use same software to prepare for the exact same dataset or they belong to a series of LDN applications for the same dataset.

✔️ No CID sharing has been observed.

[^1]: To manually trigger this report, add a comment with text checker:manualTrigger

[MianmianSH]

Continuing to solve the problems in filplus-checker

[herrehesse]

@MianmianSH I am sorry. I do advise notaries to not sign this application as the applicant did not follow any of the FIL+ rules how the datacap was spent.

⚠️ REGION ⚠️ MINERS ⚠️ DISBURSEMENT

All of the above are not proper according to the FIL+ program rules. @MianmianSH Can you explain in to detail how what and why so we might be able to assist and help you?

[cryptowhizzard]

Hello,

I have been trying some retrieval on this nodes.

lotus net connect f01771695 f01771695 -> {12D3KooWGjG3NDWERwRNb87YLZrxBWjhAqxqyKRH8q7pUdhazxVa: [/ip4/119.36.32.147/tcp/7001]} telnet 119.36.32.147 7001 Trying 119.36.32.147... After that no response & blocked.

Miner [f01959805] is online, however it does not support retrieval at all. For example deal ID 17466804 results in : retrieve: offer error: retrieval query offer errored: failed to fetch piece to retrieve from: getting pieces for cid bafybeigppcsgq4i5bzpzhieggrhovkqhkhhivsecax6g6vebwu3uiz5qdm: getting pieces containing block bafybeigppcsgq4i5bzpzhieggrhovkqhkhhivsecax6g6vebwu3uiz5qdm: failed to lookup index for mh 1220cf78a468711d0e5f93a086344eeaaa0751ce8ac88205fc6f5481b5374467b01b, err: datastore: key not found

Miner [f01964215] root@chain2 ~ # telnet 14.17.106.229 12891 Trying 14.17.106.229... After that no response & blocked.

On a last ditch attempt i tried on of your other providers:

lotus state get-deal 19036880 { "Proposal": { "PieceCID": { "/": "baga6ea4seaqcxveoajelqihc3aacrj66ylv6dyg5vrg3nthruzeahzipwiuaefq" }, "PieceSize": 34359738368, "VerifiedDeal": true, "Client": "f01913737", "Provider": "f01964253", "Label": "uAXASIJO9QVCSXigpWOUCrNei34rWhWKPW-mQ9wkZRFEQKgbS", "StartEpoch": 2440165, "EndEpoch": 3983937, "StoragePricePerEpoch": "0", "ProviderCollateral": "8679344333471612", "ClientCollateral": "0" }, "State": { "SectorStartEpoch": 2431206, "LastUpdatedEpoch": 2508560, "SlashEpoch": -1, "VerifiedClaim": 1553926 } }

lotus client retrieve --provider f01964253 uAXASIJO9QVCSXigpWOUCrNei34rWhWKPW-mQ9wkZRFEQKgbS test.car It timed out after 5 minutes.

Conclusion: None of the data stored up to now is available for retrieving. This is against the rules of FIL+

Please contact your SP's an remedy the situation before any more datacap can be granted.

[MianmianSH]

Continuing to solve the problems in filplus-checker ，Above I have detailed how I would tune the questionIf you are not support。 @cryptowhizzard @herrehesse please stay away from my LDN issue !

[lvschouwen]

Continuing to solve the problems in filplus-checker ，Above I have detailed how I would tune the questionIf you are not support。 @cryptowhizzard @herrehesse please stay away from my LDN issue !

You are aware @cryptowhizzard is a well known and respected notary within the FIL+ community? And now you are saying to him; "Stop doing due diligence!"

Work with the community to restore trust in this LDN because you are loosing it really quickly.

[MianmianSH]

I have never heard of a "respect notary" selection activity in the community. Please choose your words carefully and try to express your own personal views, not to represent everyone. In addition, my aversion to some notaries does not mean that I am in conflict with the Fil+ rules. Please do not change the concept and equate the notary with the FIL+ governance rules. I have expressed my willingness to correct and correct the existing problems many times The plan, judging from the recent progress, is also quite effective. I feel that I have the right to judge whether a notary examines my LDN with the purpose of discrimination and suppression. Can you guarantee that every notary is fair, open, friendly and unselfish? If you can't guarantee it, then as a client, you have the right to question the notary and express my attitude. If your small group maintains each other and prevents other clients and notaries from questioning, I will also question whether you have conflicts of interest, or whether it is a non-compliant association.

[MianmianSH]

If you only focus on problems that existed in the past, but turn a blind eye to the progress of client fixes, then I have every reason to doubt your motives. When filplus-checher was not online, the client did not know the rules, and made corrections after the rules became clear. As a responsible notary, it should supervise the client to make corrections, and at the same time recognize the results of the corrections, instead of blindly suppressing them.

[cryptowhizzard]

?

The rules for fil+ have been there for more then one year.

Store in multiple regions / continents. Make sure you have a minimum of 4 sp’s in different regions with different organisations The data must be retrievable hence the machines must be accessible over the internet.

Do i understand correctly from what you say that someone else is in charge of storing your data and you did not know what he or she was doing? If so, can you elaborate who he / she is so we can verify?

The only thing that changed was the CID checker last months. It helps notary’s to detect fraud. However all the way you could have checked yourself if data was retrievable? And is the data stored that needed to be stored? If it was not you that did the preparation you could have chosen to use other SP’s or another data preparer that was transparant like kernlogic, piknik, techgreedy etc.

Btw, the discrimination thing is getting old. I have signed on multiple LDN’s from China. But not on the ones where CID sharing was committed.

My suggestion is that you give the things above some thought and provide some clarity. If you want a second chance then i suggest giving notary’s and community the transparency needed and act like it instead. Where is the future storage plan? Where are you going to store? Do they provide retrieval and what is their reputation?

[NDLABS-Leo]

The connectivity of this node is still not good, it is recommended to let the technology solve it first

[MianmianSH]

So sorry, I didn't pay attention to the news because of the holiday. I immediately contacted SP to resolve this problem.

[MianmianSH]

@NDLABS-OFFICE Can you try it again? It works in my local environment now.

# lotus net connect f01964253
f01964253 -> {12D3KooWRL2hst7FLdDd4QwBjKzRvAzY6C1dWhEr6S8bpcJAaYp5: [/ip4/120.133.132.150/tcp/12912]}
ERROR: failed to parse multiaddr "f01964253": must begin with /

# telnet 120.133.132.150 12912
Trying 120.133.132.150...
Connected to 120.133.132.150.
Escape character is '^]'.
/multistream/1.0.0

# lotus client query-ask f01964253
Ask: f01964253
Price per GiB: 0 FIL
Verified Price per GiB: 0 FIL
Max Piece size: 32 GiB
Min Piece size: 56 KiB

[cryptowhizzard]

Hi,

I was able to retrieve data from your set .

http://www.datasetcreators.com/downloadedcarfiles/f01913737-f01964215-19795860-baga6ea4seaqjveyyhfnauj6v77mj46rlalyrpccyspdfhaebibvriocssjdruni.car1

[kernelogic]

checker:manualTrigger

[filplus-checker-app[bot]]

DataCap and CID Checker Report Summary[^1]

Storage Provider Distribution

⚠️ 1 storage providers sealed more than 30% of total datacap - f01964215: 31.09%

⚠️ 3 storage providers sealed too much duplicate data - f01959805: 63.69%, f01964215: 72.07%, f01981603: 28.35%

Deal Data Replication

⚠️ 53.30% of deals are for data replicated across less than 4 storage providers.

Deal Data Shared with other Clients[^3]

⚠️ CID sharing has been observed. (Top 3)

• 160.00 GiB - f1gfkibb5ugknyxhiyy6n6vxapjvwgp5aucwkwyna - BeijingYuanshu Landscape Planning and Design Office

[^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> ...

Full report

Click here to view the full report.

[kernelogic]

@MianmianSH can you explain the duplicate data reported by the CID Checker? f01959805: 63.69%, f01964215: 72.07%, f01981603: 28.35%

[MianmianSH]

@kernelogic Sorry about that, because the filplus-check did not appear before, as a client, I do not understand the details of the rules, resulting in multiple warnings. For these problems, we will continue to fix them in the next round of seal process. Please support us in this round, and I will synchronize the restoration results to you in the future.

[kernelogic]

Thanks for the honest answer. In conjunction of the retrieval success, I'm willing to support one round.

[kernelogic]

However, I cannot find it in the signing website

[MianmianSH]

@kernelogic Thanks for your support, I will find someone fix it .

@simonkim0515 @fabriziogianni7 Can you help me resolve the problem above?

[galen-mcandrew]

After refreshing and waiting for the 396 readytosign to load (wowza), I can search and find 919.

[MianmianSH]

@galen-mcandrew Galen, Thank you so much!

[kernelogic]

Request Proposed

Your Datacap Allocation Request has been proposed by the Notary

Message sent to Filecoin Network

bafy2bzacebr6p2fvaotd4za4yi52zfq6hnx524vqyfueschfd36iplvsh25i6

Address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Datacap Allocated

640.00TiB

Signer Address

f1yjhnsoga2ccnepb7t3p3ov5fzom3syhsuinxexa

Id

f956f6a4-a8ba-4a5d-a5ce-cf1b0a242965

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

[psh0691]

Request Approved

Your Datacap Allocation Request has been approved by the Notary

Message sent to Filecoin Network

bafy2bzacearxg53hf7k5dvcpovmkhuh4qiwzudjdg7izey6tnyxclrmsohl66

Address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Datacap Allocated

640.00TiB

Signer Address

f1qdko4jg25vo35qmyvcrw4ak4fmuu3f5rif2kc7i

Id

f956f6a4-a8ba-4a5d-a5ce-cf1b0a242965

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

[large-datacap-requests[bot]]

DataCap Allocation requested

Request number 7

Multisig Notary address

f02049625

Client address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

DataCap allocation requested

640TiB

Id

34575ba9-f9e9-4226-8b79-14c7e0efba92

[large-datacap-requests[bot]]

Stats & Info for DataCap Allocation

Multisig Notary address

f01858410

Client address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Rule to calculate the allocation request amount

800% of weekly dc amount requested

DataCap allocation requested

640TiB

Total DataCap granted for client so far

5.820766091346746e+63YiB

Datacap to be granted to reach the total amount requested by the client (3.5PiB)

-7.03B

Stats

Number of deals	Number of storage providers	Previous DC Allocated	Top provider	Remaining DC
55400	12	640TiB	24.86	154.68TiB

[sxxfuture-official]

retrieve test OK

[sxxfuture-official]

Request Proposed

Your Datacap Allocation Request has been proposed by the Notary

Message sent to Filecoin Network

bafy2bzacebaaddhpmqux543xweohzho2jc7bmu6i42dtafuwkffefgem2vsmm

Address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Datacap Allocated

640.00TiB

Signer Address

f1foiomqlmoshpuxm6aie4xysffqezkjnokgwcecq

Id

not found

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

[Bitengine-reeta]

Request Approved

Your Datacap Allocation Request has been approved by the Notary

Message sent to Filecoin Network

bafy2bzacecjqf2ntdwf3qps4mcwdakngipn4qxtehprhxpaebiikqtcamesye

Address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Datacap Allocated

640.00TiB

Signer Address

f1jyvhxp4kmwreo22ke4itspraznpudw3uqaink5i

Id

not found

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

[Bitengine-reeta]

[cryptowhizzard]

Why are you the same user as #919

Your wallets were funded from f3ri4kzyi6qxpxwvhgwv4a6zhtkzdnren5fbdirase5nxm2hgmgn4gek7mx3vhr5ec2tekfahqwqigyurnv6gq

[cryptowhizzard]

checker:manualTrigger

[filplus-checker-app[bot]]

DataCap and CID Checker Report Summary[^1]

Retrieval Statistics

• Overall Graphsync retrieval success rate: 1.39%
• Overall HTTP retrieval success rate: 0.00%
• Overall Bitswap retrieval success rate: 0.00%

Storage Provider Distribution

⚠️ 2 storage providers sealed too much duplicate data - f01964215: 52.21%, f01981603: 28.35%

Deal Data Replication

✔️ Data replication looks healthy.

Deal Data Shared with other Clients[^3]

⚠️ CID sharing has been observed. (Top 3)

• 160.00 GiB - f1gfkibb5ugknyxhiyy6n6vxapjvwgp5aucwkwyna - BeijingYuanshu Landscape Planning and Design Office

[^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> ...

Full report

Click here to view the CID Checker report. Click here to view the Retrieval report.

[cryptowhizzard]

@sxxfuture-official

You sealed 61% from the granted datacap to your own miners. This while you signed of on this application yourself.

[sxxfuture-official]

@cryptowhizzard In fact, this LDN was recently encapsulated by SXX, which is f01964215. We participated in this project a long time ago. In order to fix the problem that the duplicate is too high, we can only add more unique data to f01964215 again for balance.

[cryptowhizzard]

@cryptowhizzard In fact, this LDN was recently encapsulated by SXX, which is f01964215. We participated in this project a long time ago. In order to fix the problem that the duplicate is too high, we can only add more unique data to f01964215 again for balance.

Thanks for responding and explanation.

[large-datacap-requests[bot]]

DataCap Allocation requested

Request number 8

Multisig Notary address

f02049625

Client address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

DataCap allocation requested

320TiB

Id

c441c2ea-c1e6-4116-8678-c957e3ea9542

[large-datacap-requests[bot]]

Stats & Info for DataCap Allocation

Multisig Notary address

f02049625

Client address

f1w5ydukkf5hmg2en4gydvltvhp3fznwr2tpaoagi

Rule to calculate the allocation request amount

400% of weekly dc amount requested

DataCap allocation requested

320TiB

Total DataCap granted for client so far

5.8207660913467465e+78YiB

Datacap to be granted to reach the total amount requested by the client (3.5PiB)

5.8207660913467465e+78YiB

Stats

Number of deals	Number of storage providers	Previous DC Allocated	Top provider	Remaining DC
17714	3	640TiB	51.4	156.34TiB