Blockchain Drive system architecture and data flows

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ankit-bista/Final-Project/llms.txt

Use this file to discover all available pages before exploring further.

​

Authentication flow

1. The browser calls GET /auth/nonce?address=<wallet>. The backend generates a random 16-byte hex nonce, stores it against the user record in MongoDB, and returns it.
2. The browser passes the nonce string to MetaMask, which signs it as a personal message (off-chain — no gas cost).
3. The browser posts { address, signature } to POST /auth/verify.
4. The backend calls ethers.verifyMessage(nonce, signature) to recover the signer’s address. If it matches the claimed address, the session is established.
5. An HTTP-only session cookie (maxAge: 24h, sameSite: lax) is written. All subsequent requests are authenticated by this cookie.
6. On first login, if the authenticated wallet matches the MAIN_ADMIN_WALLET environment variable, the backend automatically grants that user the admin role.

const recoveredAddress = ethers.verifyMessage(expectedNonce, signature);

if (recoveredAddress.toLowerCase() === normalizedAddress) {
  req.session.userId = user.id;
  // ...persist session, clear nonce, bootstrap default drive
}

​

File upload flow

1. The browser submits a multipart form upload to the Express backend (handled by multer).
2. If encryption is enabled, the file buffer is encrypted with AES on the client before sending; the backend receives the ciphertext.
3. The backend calls ipfs.add(buffer) via ipfs-http-client, which sends the data to the Kubo daemon at IPFS_API_URL. Kubo returns a CID.
4. The backend generates a custom hash from the file content and stores a file record in the MongoDB files collection, referencing the CID, custom hash, owner, drive, and optional encryption metadata.
5. The blockchain service calls updateQuotaAndRecordFile(userAddress, fileId, customHash, sizeBytes). In real mode this submits two on-chain transactions — one to update the quota and one to record the file. In mock mode it writes the metadata as hex calldata in a zero-value transaction.

const { cid } = await ipfs.add(buffer);
return cid.toString();

​

Access control

​

Database RBAC

​

Smart contract permissions

function canUserAccessFile(address userAddress, string memory fileId, string memory action)
    external view returns (bool)
{
    // owner/uploader can do all actions
    if (f.uploader == userAddress) return true;

    AccessGrant memory grant = accessByFileAndUser[key][userAddress];
    if (!grant.active) return false;
    if (grant.expiresAt != 0 && grant.expiresAt < block.timestamp) return false;
    // ...role-based action check
}

​

Encryption

• The encryption key is derived from the user’s MetaMask wallet, so only the wallet owner can decrypt.
• The owner’s encrypted AES key is stored alongside the file metadata, allowing the backend to store re-encrypted copies for recipients when sharing an encrypted file.
• The backend can also persist encrypted key payloads as on-chain transaction calldata via storeEncryptedKey(fileId, recipientAddress, encryptedKeyPayload) — this works in both mock and real contract modes without ABI changes.

​

Smart contract

​

Port reference