ZeroDRIVE: Building a Cloud Drive with Telegram Storage

ZeroDRIVE presents a familiar file workspace over an unusual storage arrangement. Its browser interface organizes uploads, folders, previews, and sharing, while a Go service connects those operations to Telegram storage.

The interesting engineering work happens between those two views. A storage service can hold a file, but a drive application must also remember its name, folder, owner-facing metadata, and how it can be retrieved. ZeroDRIVE separates that application state from the underlying file transport.

The live application starts with sign-in. With authorized access, a useful first session is to create a folder, upload a small file, rename it, preview it, and retrieve it again. That short loop tests whether the drive makes storage understandable from the user's side.

A File Workspace Above the Storage Layer

The frontend uses React, TypeScript, and React Router. The API uses Go and Fiber. The browser communicates with application routes; the backend owns the authenticated Telegram session and performs storage operations through MTProto.

This keeps provider-specific details away from the ordinary file workflow. Users interact with files and folders. The service handles the remote references needed to upload and retrieve their content.

The backend also tracks metadata and manages thumbnails and preloaded media beneath its configured storage path. Those records make the interface possible: remote content alone does not explain where a file belongs in a folder tree or which preview should appear beside it.

Following an Upload Through the System

The route layer exposes upload configuration, ordinary and streaming uploads, and cancellation by upload ID. The frontend can obtain the server's upload constraints before sending a file, while the service handles the Telegram transfer and the application's resulting record.

Conceptually, the flow is browser selection, authenticated API request, remote content transfer, metadata registration, and a refreshed file listing. The file record carries the reference needed to retrieve content later. Folder placement and naming remain application concerns, even though the remote provider stores the payload.

The protected API sends Cache-Control: no-store for its responses. The source comment identifies a specific failure this avoids: a browser retaining an empty or partly populated folder response while an upload queue is still filling it. To a user, stale metadata looks like a failed upload even if the transfer succeeded.

This is why the completion state needs to connect transfer progress with the eventual listing. A progress indicator reaching its end is only useful when the new item becomes findable. The project uses the Telegram API through its backend; provider authentication is independent of that browser interaction.

Metadata Is Part of the Product

A drive can fail in two separate ways. The underlying bytes can disappear, or the application can lose the information needed to find and organize them. The second failure can make intact storage look empty.

ZeroDRIVE includes remote metadata backup and restoration. During startup, the service attempts to restore its database from the stored backup. Database flushes enqueue backup work, and a debounce window reduces repeated writes when changes happen close together.

This is especially relevant to its Render configuration. The free backend uses temporary local storage, so a restart cannot rely on yesterday's local files still existing. Its authenticated storage session is bootstrapped from deployment configuration, metadata is recovered remotely, and media caches can be recreated.

The architecture distinguishes durable application records from disposable working files. That distinction is more useful than treating every directory on the server as equally permanent.

The backup worker introduces a recovery tradeoff. Debouncing combines closely spaced metadata changes into fewer remote writes, but the interval before a completed backup is still meaningful. The server includes shutdown flush handling, yet an abrupt process failure can behave differently from an orderly shutdown. A recovery exercise should check the most recently completed backup rather than assume every visible mutation is already durable.

One practical development test is to create a folder, upload a disposable file, wait for a confirmed backup, restart the API, and verify the folder and download still resolve. That tests the relationship between content and metadata. It is a proposed validation workflow, not a claim that this article performed a production restart.

Previewing Content Has Its Own Costs

Listing files and previewing them are different operations. A file list mainly needs metadata. A thumbnail, an image preview, or a video stream may require fetching content, producing a derivative, or keeping a temporary cache.

ZeroDRIVE's backend includes thumbnail and media cache handling rather than assuming the frontend can cheaply read every remote file. The deployment documentation also accounts for bandwidth, concurrency, and backup frequency.

These controls matter because a pleasant file interface can create expensive behavior underneath it. Loading a screen should not silently become a request to download every large file visible on that screen.

Why Seeking a Video Is a Backend Feature

ZeroDRIVE's download handlers advertise byte-range support and parse the requested range. A valid partial request returns 206 Partial Content with Content-Range; an out-of-bounds range produces 416. The handler can retrieve the requested bytes through the Telegram service or an applicable media cache.

That affects an ordinary action: dragging a video playhead forward. A media player may request a different portion of the file rather than consume everything from the beginning. Correct range handling connects the browser's playback controls to remote storage. MDN's range-request guide explains the HTTP exchange.

The implementation also handles HEAD requests and validators such as ETags. A client can inspect a resource without asking for its full body, and validators help it distinguish a reusable representation from one that has changed.

Caching provides another useful distinction. A thumbnail or cached media block can be regenerated; folder relationships and storage references must survive. Treating both as ordinary files on a temporary server would make a harmless cache eviction indistinguishable from loss of the drive's organization.

Authentication Belongs at the Boundary

The application has an authenticated API and a separate storage-provider session. They serve different purposes: application authentication controls access to the drive, while the Telegram session allows the service to reach its remote storage.

The browser does not need the provider's credentials to show a folder. Those credentials and session values stay in backend configuration. File-sharing behavior also needs to be treated as an application decision rather than an automatic consequence of where the bytes are stored.

Using Telegram for transport does not by itself establish end-to-end encryption or guarantee permanent availability. The project is a working storage integration with provider dependencies, not evidence of those stronger properties.

File and folder sharing have separate public routes, and the protected API includes revocation routes. Public downloads also pass through bandwidth, request-rate, and concurrency guards. The result is an access path defined by the drive application, rather than exposing the authenticated provider session to recipients.

Revocation should be interpreted carefully: it can prevent future access through a link, but it cannot remove a copy already downloaded by someone else. That distinction gives users a realistic understanding of what the share control does.

Making People Confident Enough to Return

The API includes recent files, starred items, trash, restore, and permanent deletion. These operations support different user needs: find work quickly, mark frequently used material, recover an accidental removal, or deliberately delete it.

I would evaluate the interface through a small set of tasks: find yesterday's upload, share one intended item, revoke that share, and restore a trashed file. Completion rate and mistaken actions would reveal more about the drive than an unqualified count of button clicks. No retention or adoption figures are claimed here.

The technical structure behind those tasks is visible in the ZeroDRIVE project record. Readers interested in the routing framework can also explore Fiber's documentation, while the broader Lab Projects collection places this storage experiment alongside the other apps.

The Deployed Application

ZeroDRIVE runs with a separately deployed frontend and API on Render. The live frontend begins at its sign-in screen. The project page records the interface, stack, and purpose without exposing backend configuration.

The project shows how much of a cloud drive lives above storage itself. Upload and download are only part of the work. Organization, metadata recovery, previews, authentication, and deployment state make the stored files usable as a coherent workspace.