How yanDNA™ Stores Your Data

yanDNA™ (Decentralized Node Assembly) is a decentralized storage product that incorporates IPFS technology and will be available both to consumer and enterprise users when the full version product is released.

yanDNA stores your data and this is how:

Uploading Files:

(1.) Individual Users can upload a file from the yanDNA frontend interface (available at yanDNA.io) where it is then sent to yanDNA backend at (2.) Data Processing.

(2.) The meta information of uploaded files in the server at Data Processing are fetched and stored in the File Meta Database (a.). The meta file contains: file name, file type, and file size. While the file is being uploaded from the user, the server proceeds with splitting the file, encrypt it and upload it directly to Validating Server (3.)

(3.) The Validating server takes care of randomly distributing the files to the IPFS Node Network (yanNetwork) (4.) At the same time, it also uploads files to a dedicated server (a.) for long-term storage.

(4.) The IPFS Node Network, which can be installed and supported directly by existing servers connected to a PAC Protocol Masternode, has the stored files from the end-user. The files are not readable for the Masternode Owner, or publicly accessible unless permission is granted from the owner of the file. This is ensured by the file being split across the available servers, encrypted (with each split file having its own encryption password), and uploaded to a different IPFS Node Network.

An unlikely scenario example: Assuming someone happens to be able to gain access to a file that was stored among the network's decentralized digital architecture, and successfully decrypts this single file by brute-force: this one file itself would be useless to gain access, since only one part of the many split files was discovered. These files are distributed across other servers, and the bad actor wouldn’t know which separate files belong to each specific file, or in what sequence. This provides an increased level of security, by decentralizing the storage of any one file amongst a scalable network, and even masking the physical location of the stored file.

Successfully decrypting a file by brute-force is a highly unlikely scenario:it’s like trying to brute-force discover the private key of the public key. But even in that scenario, it would have to be performed on all specific servers holding the file splits of any individual file, along with each individual encryption.

Summary

Dowloading Files:

(1.) User wants to download a file, which initiates a request at “Data Processing Server” (2.) for this specific file.

(2.) The Data Processing Server checks all split files for this requested file, and sends a request to “Validating Server” (3.) in queue to download all split files.

(3.) The “Validating Server” checks if the file split exists in the IPFS Node Network and, if it does, pulls it from the IPFS Node Network, redirecting the file to the Data Processing File (2.) - If the IPFS Node Network is not responding or has lost the file, it retrieves the data from “Dedicated Storage Server” (a.) and places it in IPFS Local Cache (a.). In this case, the flle re-uploads back to the IPFS Node Network and is simulatneously sent back to “Data Processing” (2.)

(2.) The Data Processing (2.) now has the encrypted split files from the “Validating Server” (3.) - The Data Processing Server then decrypts the split files, merge the file pieces into a single file, and send the file, including meta files from the database (a.), directly to the user (1.) who requested the download.

Shared public files work differently:
If the user is pulling a public file (a file which has been granted permission to be shared publicly), the file will be pulled once from the “IPFS Node Network” (4.) and then this file will be stored on “Cache Server” (a.). The next time the user requests this public file, it is pulled directly from “Cache Server” (a.). All files in cache are removed after 24 hours; this step is repeated if the user wants to pull this public file again.

All private files are directly pulled from “IPFS Node Network” (4.) and are not stored in “Cache Server” (a.). - The password of this public file is stored in our Database as plain text in order to decrypt on the fly and show it to the public user requesting the file. The file itself is still stored as originally encrypted

Summary