Thanks for sharing I'll add this to my reference lib.
Unfortunately, from a cursory review their design is, well, feckless. Their your claims about it (sorry, nothing personal) fall short in a few key areas.
To justify my harsh criticism I felt obligated to explain my conclusions in excruciating detail below and to compare them to the leading edge in flexible data publishing tech for
#DeSci:
1) I wouldn't call it a 'big study", or even a study at all. The paper you linked is a report describing a dApp a private for-profit company made. Unfortunately, neither the frontend nor contract code is open source, so the benefits of putting anything on-chain without essential code auditability are heavily compromised. A hypothesis based "study" they could have done would be to use their tool to index a benchmark dataset like OpenAlex, NCBI, etc vs alternative solutions in performing some useful action (e.g. storage/retrieval times, cost/size per object, en/decryption, verifiability, etc).
2) As a professional scientist and member of the scientific community I hold a strongly contrarian perspective to the establishment regarding peer reviewed paper count. I'm pretty confident most if not all of my desci contributor colleagues would agree.
3) Base64 encoding doesn't do much other than prevent BNB from throwing errors when the contract writes the data to it (bc of special characters that might be in text). The data isn't encrypted so their tool can only be used to create references for existing data in the public domain - which defeats their stated purpose for building the app...
"Welcome to the first 100% on chain decentralized storage Dapp for biomedical and general purpose data (such as text, images, audio and video) providing you with Identity, Timestamping, Content and Immutability (ITCI) for your business."
It doesn't make economic/business sense to store data on BNB, an EVM chain with limited horizontal scaling. They should have at least enabled the opBNB L2 to leverage a rollup and mitigate cost data volume settled on L1. It would cost nearly $80 to save the word "test" using their dApp (screenshot #1). No wonder they didn't run a benchmarking trial.
-----Alternate Solutions-----
A)
@oceanprotocol uses a "provider" to encrypt/decrypt URLs of user published data (accessible via HTTP), then they store tokenized references on-chain which grant the owner/purchaser permission to decrypt a target URL. They've got a solid metadata (object labeling) system & built a compute-to-data interface that unlocks actual usability for sensitive/private data, such as almost any business would require.
B)
@eas_eth likewise employs multiple privacy options and scalability solutions for publishing data and/or references on-chain.
Users can publish attestations offchain of any size for free, or they can enter encrypted data manually into the appropriate schema field if included in an onchain attestation. EAS released a sha256 hash tool for easy & non-reversible encryption of sensitive data. For even higher security, they created a "private data" attestation schema that encrypts the contents in a Merkle Tree to support selective disclosure (read permissions) of specific fields in the a given data schema. EAS timestamps & UX are a bit clunky, but overall it's an extremely versatile platform set of standards.
3c) TLDR; at
@HyperfilesOrg we're combining the best of both Ocean & EAS with features to support co-governance of collaboratively generated digital data assets. Most of the engineering & integration design was done in Q1-2024, with some groundwork laid in 2023 during two hackathons. Q2-2024 is mainly building/shipping those designs, and we're even adding things to the roadmap like a smart contract to calculate global reputation scores for the Hyperfiles knowledge graph (a social graph with infinitely customizable schemas, version control, automated object classification, and user reputation scoring).
------Hyperfiles Deets------
We're implementing encryption by default for data objects published using our dApp (starting w/ sha256, then Lit Protocol PKPs). We're also replicating the Ocean "provider" architecture for a second layer of security & data provisioning during URL endpoint sharing.
Hyperfiles reference objects are stored in the open-source Near socialDB contract for typically ~$0.07 per object. Hyperfiles a superset to EAS attestations so users can select the EAS attestation standard as a Hyperfiles schema. This interoperability enables users to query standardized metadata across multiple sources, facilitating reusable elements & enforcing composability between completely unrelated data objects, as well as dynamic data object rendering.
References (and subsequent versions) are uniquely timestamped by their blockheight. Human-readable object paths uniquely identify references stored under each user's personal data tree in socialDB.
The entire Hyperfiles app - every single React frontend component - is also stored immutably on the Near socialDB contract via path & blockheight (the same way references are stored). The code is easily viewable/forkable directly from the app itself if users want to customize or contribute new components (screenshot below).
Comparatively, the INNBC claim to be "the first 100% on chain decentralized storage Dapp for biomedical and general purpose data" is frankly, complete BS and highlights just how flawed & ineffective peer-review is when managed by exploitative publishers. Their dApp is not 100% on-chain and it's definitely not the first to do what it does.
Hyperfiles already has read/write adapters for off-chain storage layers: IPFS and GitHub. A suite of additional default adapters in the Q2-2024 roadmap include local storage, Notion, Obsidian, Arweave, Ceramic, Verida, EVM Chains (via Solidity ABI), and even a few indexing services as data input options.
It's taken a systematic and relentless approach to engineer, integrate and distill the diversity of features behind Hyperfiles into our current roadmap of smart contracts & frontend UI components. You can try the open beta at
hyperfiles.org and access our prolific documentation wiki from the app as well.
Join the Hyperfiles TG group and I'll send you some free
$NEAR tokens to pay storage deposits & gas fees.
t.me/hyperfiles
-----References-----
In-progress "development" version of Hyperfiles:
hyperfiles.org/hyperfiles.ne…
List of on-chain components (widgets):
hyperfiles.near.social
Off-chain code repos (React components, "gateway" app to render React code from Near), and our smart contracts:
github.com/hyperfiles-org/