Small Grant Proposal — DeinLex

Grants Proposed
1

INTRODUCTION

Project Name: DeinLex
Name of individuals submitting the proposal: Princess Uhiene (Code Duchess) & Gift Eleojo (Gifetea)

Princess Uhiene (Code Duchess) is a developer with hands-on experience building full-stack applications in React, TypeScript, and Node.js. She previously contributed to two Sia Foundation-funded and completed grants under Dapp Mentors — SiaPeopleLearn, a decentralized eLearning platform built on Sia Renterd, and SiaLearn, a developer education program that produced a fully integrated video streaming application on Sia.

Gift Uhiene (Gifetea) is a developer with experience in smart contract development, full-stack Web3 applications, and developer tooling. She has spoken at multiple Google Developer Events in Port Harcourt, Nigeria, delivering technical sessions to local developer communities, and participated in the Encode Marathon 2025 hackathon as part of a winning team alongside Princess Uhiene.

Describe your project

People share sensitive files every day, large videos, high-resolution photos, datasets, scanned documents, and contracts over platforms like Google Drive, Dropbox, and WeTransfer. These services can access, modify, or delete your files at any time. Users have no way to prove a file hasn’t been changed after it was uploaded.

DeinLex is a decentralized file-sharing application built natively on Sia using indexd. A user uploads any file directly from their browser. The file is encrypted client-side before it ever leaves the device, stored across Sia’s distributed host network via indexd, and assigned a cryptographic integrity receipt with a SHA-256 hash tied to the upload. Anyone with the share link can download the file and independently verify it is byte-for-byte identical to the original upload, without trusting any server, company, or admin.

DeinLex is designed primarily for large single-file videos, high-resolution images, datasets, and documents where reliable availability and tamper-evidence matter most. It replaces vendor-locked tools with a Sia-native alternative where users own their data completely.

We’re building DeinLex because we believe that verifiable, user-owned file sharing should exist as a real tool not just a concept and Sia makes it possible in a way no centralized platform ever can.

How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?

Centralized file sharing tools take ownership of your data the moment you upload. They can alter, delete, or hand it over without your knowledge and you have no way to prove otherwise.

Files are encrypted in the browser using the WebCrypto API before they ever reach our middleware. indexd and the Sia host network only ever store encrypted bytes; they have no way to read your data. The integrity receipt is computed on the user’s device before upload, embedded in the share link, and recomputed on the recipient’s device after download. Our servers are not involved in verification at all. A user can independently confirm their file is untampered without trusting DeinLex, indexd, or any Sia host.

This is what user-owned data actually means in practice, not just stored on a decentralized network, but verifiable and private by construction.

Are you a resident of any jurisdiction on the restricted list? No.

Will your payment bank account be located in any jurisdiction on that list? No.

GRANT SPECIFICS

Amount requested: $10,000
The total grant requested is $10,000, to be paid in monthly USD wire transfers.

  • $8,500 — Development
    Covers three months of development work by both Princess and Gift across the full application stack.

  • $1,000 — Infrastructure
    Funds 12 months of server hosting for the Node.js middleware and public demo deployment, ensuring DienLex remains accessible well beyond the grant period.

  • $500 — Security Review
    Allocated for an independent review of the client-side encryption and credential-handling implementation to validate the security model before public release.

High-level architecture overview

Data flow end-to-end:

  1. User selects a file in the browser, any size, any type

  2. WebCrypto API computes the file’s SHA-256 hash, this becomes the integrity receipt

  3. WebCrypto encrypts the file using AES-256-GCM, the key is derived from the user’s keypair and never leaves the client

  4. The browser sends only encrypted bytes to the Node.js middleware — no plaintext ever crosses the network

  5. Middleware calls POST /slabs — indexd distributes erasure-coded encrypted shards across Sia hosts

  6. Middleware calls POST /objects — registers the SHA-256 hash as the object key alongside the encryptedMasterKey and encrypted metadata

  7. User receives a shareable link containing the object key and enough context for the recipient to fetch and verify

  8. Recipient calls GET /objects/{key}, downloads the file, decrypts it, recomputes the hash, and confirms it matches the receipt — if a single byte has changed, verification fails automatically

Security practices:

  • No plaintext leaves the client. All encryption is performed in the browser via the WebCrypto API. The middleware and indexd only ever handle encrypted bytes

  • Content verification on every download. The SHA-256 hash is recomputed on the recipient’s device and compared against the receipt before decryption. Tampered or corrupted files are rejected

  • Key isolation. The AES-256-GCM key is stored in indexd’s encryptedMasterKey field, locked to the user’s public key. DeinLex’s server never holds a usable decryption key

  • Admin API never exposed publicly. The App API uses ed25519 keypair signing for all authentication

  • All secrets stored in environment variables, never committed to source control

  • HTTPS/TLS across all communication between the browser, middleware, and indexd

  • npm audit and Dependabot for dependency hygiene. Sia-specific dependencies limited to @siafoundation/indexd-js

Goals and timeline

Month 1 — Core foundations

  • GitHub repository and CI pipeline setup

  • React frontend and Node.js middleware scaffolding

  • indexd authentication and app registration flow

  • In-browser AES-256-GCM encryption and SHA-256 hashing via WebCrypto API

  • Large file upload and download via indexd including chunked streaming for multi-GB files

  • Share link generation with embedded integrity receipt

Month 2 — Verification interface and beta

  • File integrity verification UI — recipient pastes link, file downloads, hash verification runs automatically, pass or fail result displayed clearly

  • File management interface — users browse their uploaded files, view receipts, copy share links, delete files

  • Private beta with real users across a range of file types and sizes

  • Bug fixes and edge case hardening from beta feedback

Month 3 — Hardening and public release

  • Independent security review of the encryption implementation and credential handling

  • Cross-browser testing and documented compatibility notes for Chrome, Firefox, and Safari

  • Public demo deployed at a stable URL

  • Full user-facing documentation published

  • Final grant report submitted to the Sia Foundation

Who is the target user?

Anyone who needs to share large files and be able to prove those files have not been altered. This includes:

  • Individuals sharing contracts, medical records, financial documents, or personal photos who want a Sia-native alternative to Google Drive and Dropbox

  • Developers and researchers sharing large datasets, build artifacts, or high-resolution assets where tamper-evidence and reliable, contract-based availability matter

  • Journalists and investigators who need source materials and recordings stored somewhere that cannot be taken down or quietly modified

  • Legal professionals and NGOs who need independently verifiable file records

  • Privacy-conscious users looking for a vendor-lock-in-free replacement for WeTransfer and similar tools

Why is this use case needed and why is Sia the right fit?

Demand for private, verifiable file sharing is well established. Tools like Magic Wormhole, OnionShare, and Keybase File System have large active user bases precisely because people distrust centralized storage for sensitive files. WeTransfer processes billions of transfers annually yet offers zero tamper-evidence and full vendor control. There is no mainstream indexd-native equivalent in the Sia ecosystem today.

Sia is the right fit architecturally. Unlike IPFS-based tools, Sia’s host contract model ensures files remain available and retrievable over time, not just cached temporarily. The combination of client-side encryption, indexd’s content-addressed object storage, and erasure-coded distribution across independent hosts creates a tamper-evidence model that no centralized tool can match by architecture, not just by policy. The integrity receipt is verifiable by anyone without ever contacting DeinLex’s servers.

What are your plans for this project following the grant?

Post-grant focus is on real-world adoption. Initial target users are individuals, developers, and privacy-conscious professionals whose feedback will inform what gets built next. Community channels on Discord and BlueSky will be set up at launch for feedback and updates.

Long-term, DeinLex moves to a freemium model, free for individuals, with paid storage tiers for heavier users. Storage costs are passed directly to users in Siacoin, keeping DeinLex’s infrastructure lean and self-sustaining without ongoing grant funding.

Future development directions informed by real usage after launch may include team folder sharing, mobile support, and increased file size limits as Sia host capacity grows. These are post-grant and driven by what users actually need, not built into this scope.

One thing we do plan to do naturally as the codebase matures is keep the indexd integration layer clean and well-documented, so other developers building on Sia can learn from it or adapt it. That’s not a formal deliverable of this grant but it’s something we care about as developers who benefited from reading other people’s open-source Sia code when we were getting started.

Potential risks that will affect the outcome of the project

  • Sia host availability. Development and testing will be done on the Zen testnet first. Mainnet deployment only after host availability is confirmed stable for the file sizes we are targeting.

  • Large file streaming. Multi-GB files require chunked streaming uploads to avoid browser memory limits. Streaming via the indexd slab API will be implemented and tested with representative large files, videos and datasets during Month 1, not left to the end.

  • WebCrypto browser differences. Chrome, Firefox, and Safari handle key derivation slightly differently. All three will be tested throughout development. Known limitations will be documented clearly in the public release.

  • indexd maturity. Some areas of indexd are still maturing. We plan to test against the Zen testnet early and will report any undocumented behaviour or edge cases we encounter back to the community as part of our monthly progress reports.

DEVELOPMENT INFORMATION

Will all of the project’s code be open-source? Yes. All code will be released under the MIT license.

Where will code be accessible for review? https://github.com/Uhiene/deinlex

Do you agree to submit monthly progress reports? Yes. Monthly reports will be submitted to the Sia Forum with milestone summaries and links to all relevant pull requests.

CONTACT

Email: [email protected]

Other contact methods:
Discord: code_queen_
Telegram: @Uhiene_Princess
X: @chenemi_U

2

Hello @Uhiene - thank you for this proposal!

Can you share proof of previous work for both project contributors?

Can you also note how this proposed decentralize file-sharing solution is different from the other recently submitted (and rejected) solutions?

Please note all revisions will need to be completed by Wednesday, May 20 by 5pm ET at the latest in order for this project to be put before the Committee at next week’s meeting. We also have a cap for how many proposals can be reviewed at once that we are close to hitting, so keep this mind.

3

Thank you for the quick response @mecsbecs
Proof of previous work

Princess Uhiene (Code Duchess)

Gift Uhiene (Gifetea)

How DeinLex differs from other file-sharing proposals
Most file-sharing proposals focus on upload and download alone. DeinLex is centered on verifiable file integrity:

  • Every upload generates a SHA-256 receipt computed client-side
  • Recipients independently verify the file after download, no server trust required
  • Files are encrypted in the browser, so middleware and indexd only handle encrypted bytes
4

Im curious, why would you need this given Sia objects themselves are verifiable hashes and could be seen as a content based addressing as-is. IMO, hashing the file to give a SHA256 is a very small benefit that may just give a more known hash algo but doesn’t really benefit the user any further then what has been generated by Sia.

This is part of the SDK and the entire point. every Sia app will do this implicitly unless you create a share URL. There is no difference here vs any other spin on a fileshare app or any other Sia app.

Thanks.

5

Thank you for the technical feedback, these are fair points worth addressing directly.

On the SHA-256 receipt: you are right that Sia’s content-addressed storage already provides object verification internally. The distinction DeinLex makes is exposing that verification to the recipient as a user-facing workflow. The receipt is not just for the uploader, it gives the recipient a way to independently confirm file integrity after download, without needing to understand how Sia works underneath. The goal is making tamper-evidence accessible to non-technical end users, not adding cryptographic novelty at the protocol level.

On client-side encryption: again, fair point that this is standard behaviour for Sia apps. Our emphasis on it was perhaps overclaiming as a differentiator. The more honest framing is that DeinLex combines encrypted storage with a recipient-facing verification step as a complete end-to-end workflow which we believe is currently absent as a dedicated application in the ecosystem.

6

To play devils advocate, your argument on what makes you different is a simple 1 screen UX that shows a hash to the user vs the Sia object hash as tamper proof when as stated, the Sia object already provides verification.

Boiled down, I can’t say that makes your pitch unique enough to have any additional value, and honestly I don’t see most users understanding the concept of a file hash to begin with unless the target is developers. As developers, we see file integrity hashes everywhere, but its often noise to us as well IMO until we decide we do need to verify. But non-developers generally won’t care about a file hash on their screen.. nor does an average user understand the concept to begin with.

Thanks.

7

You raise a fair point, the goal isn’t to show users a hash.

The gap we’re trying to solve is the recipient side of file sharing. Today when someone sends you a file, there’s no simple way to confirm it’s exactly the file that was originally uploaded. You either trust the sender or the service hosting it.

DeinLex makes verification part of the sharing workflow. The proof travels with the link, and the recipient gets a simple pass/fail result automatically on download, no technical steps and no trust in our servers required. Users never see a hash or need to understand what one is they just see a clear pass or fail.

So our value isn’t a visible hash, it’s turning file sharing into a trustless receive workflow built on Sia.

DeinLex isn’t a one-screen app. It has separate flows for encrypted uploads, file management, share link creation, and recipient verification, two clear user journeys: sender and receiver.

8

My point is there’s no simple way to confirm it’s exactly the file that was originally uploaded. is implicitly solved by sia itself, and more abstractly, is solved by file hashes from an eng pov.

So the tamper-proof argument is really just adding a single UX screen to give the user more trust, in theory, as the only new thing being added to a fileshare app. And as I previously stated, that doesn’t seem like something to be valuable enough to be a differentiator, just a nice value-add to an app.

Oh and another detail Middleware calls POST /objects — registers the SHA-256 hash as the object key. Sia decides what the object ID is, not the developer. The mobile app, GitHub - SiaFoundation/sia-storage-app: Private, encrypted cloud storage app that stores files on the Sia host network. · GitHub which DOES compute SHA256 hashes, just stores it in the object metadata. And if I were to do that, off my head, I would probably use a web TransformStream before sending it to the SDK and reduce any complexity, and I would not view that as middleware.

So you also need to review Quickstart - Sia Developer Docs deeper b/c you don’t understand the system well enough, it seems.

Thanks.