DiscVault

Chunked large-file storage on Discord's free-tier attachment limits, retrieved via a SHA-256-verified manifest — controlled from CLI, website, desktop exe, and Android apk.

Services
EngineeringApp Development
Industries
Dev Tools
Tools
TypeScriptNodeDiscord APISHA-256
Highlight
An attachment cap is a block size.
Live
discvault.onrender.com

A limit is something you work around. A block size is something you build on.

Discord will take an attachment up to a certain size and no larger. Every so often somebody notices this and builds a joke about it. DiscVault started as that joke and stopped being one the moment the cap stopped reading as a limit and started reading as a block size.

That reframing is the entire project. A block size is the unit every filesystem in existence is already designed around — and forty years of prior art suddenly applies to a silly idea.

Streamed, never loaded
The manifest is an inode
Rebuilt byte for byte
Chunk, hash, upload, and keep a record of where everything went.

What a filesystem already knows

Files are streamed rather than read into memory and split into pieces sized to fit under the free-tier attachment limit — which matters at 30GB, where the naive version dies on the first allocation. Chunks are pushed as message attachments in parallel, and a per-file record notes every chunk's server, channel and message.

That record is a manifest, and a manifest is an inode wearing different clothes. Once it exists, the standard questions have standard answers: a corrupt chunk is a re-fetch rather than a lost file, and resumption is free because you already know which chunks you have.

SHA-256 verifies the rebuilt file against the original, byte for byte. Without that the whole thing is a very elaborate way to lose data quietly.

Core
ChunkingSHA-256 manifestsStreaming rebuild
Clients
Node CLINext.js dashboardDiscord OAuth
Sharing
Invite code carries the IDsBring your own botNo token exchanged
Scale
2–30GB per fileParallel chunk uploadDeployed on Render
Chunks, in parallel
One manifest per file
Verified on the way back

01 / 03

What it cost

The manifest has to live somewhere, and that is a bootstrapping problem. Store it with the chunks and you need it to find them and need to find it first. Store it on our server and our server becomes load-bearing for everyone else's data. The answer — the manifest is itself a message, and the key you hold points at it — is a superblock by another name, which is reassuring and was not obvious at the time.

The invite model took longer than the chunking. Sharing access without sharing a bot token means the recipient brings their own bot, which is more friction and the only version that does not hand somebody your credentials.

Where it does not work yet

Desktop and Android clients are listed as planned and are not built. The CLI and the web dashboard are what exists.

And the honest warning the project makes in its own README should be repeated here: this is a demonstration that the primitives are more general than the product they arrive in, not a recommendation. Terms of service exist, retention policies exist, and a vendor can change their mind on a Tuesday. Do not keep anything here that you would be upset to lose.