telstore 0.1.4 → 0.1.6

package/README.md

@@ -1,78 +1,68 @@
 # telstore
 
-Split large files into 1.8GB chunks, store them on Telegram, and restore them intact.
+Split large files into chunks, store them on Telegram, and restore them byte-for-byte.
+
+telstore signs in with your own Telegram account over MTProto, not a bot: the Bot API caps
+uploads at 50MB per file, a user account gets 2GB.
+
+Needs Node.js 18+ and an `api_id`/`api_hash` from <https://my.telegram.org> → API
+development tools; `login` asks for those, your phone number and the verification code.
 
 ## Quick start
 
 ```bash
-npx telstore login                        # once only
-npx telstore config chat @my_backups      # where backups go, from now on
-npx telstore data.tar                     # split it and send it there
-npx telstore data.tar --to @somewhere     # somewhere else, this run only
-npx telstore config                       # every setting and where its value comes from
-npx telstore status                       # account, destination, unfinished backups
-npx telstore list                         # what is already stored in the destination
+npx telstore login                             # once only
+npx telstore config chat @my_backups           # where backups go, from now on
+npx telstore data.tar                          # split it and send it there
+npx telstore list                              # what is already in the destination
 npx telstore restore telstore-20260905-7f3a91
-npx telstore delete telstore-20260905-7f3a91   # take it back out of the chat, for good
-npx telstore token                        # a session token for a machine you do not trust
 ```
 
-## What you need
-
-- Node.js 18 or newer.
-- An `api_id` and `api_hash` from <https://my.telegram.org> → API development tools. The `login` command asks for both, plus your phone number and the verification code.
+## Commands
 
-telstore signs in with your own Telegram account (MTProto), not a bot. That is a hard requirement: the Bot API caps uploads at 50MB per file, while a user account gets 2GB.
+| Command | What it does |
+|---|---|
+| `telstore login` | Log in to Telegram. Add `--token` to log in with a session token instead. |
+| `telstore <file>` | Split the file and upload it. Prints the `backupId` you restore with. |
+| `telstore list` | The backups stored in the destination, newest first. |
+| `telstore restore <backup-id>` | Download every chunk and reassemble the file. |
+| `telstore delete <backup-id>` | Remove a backup's chunks and manifest from the chat, for good. |
+| `telstore status` | Account, destination, and unfinished backups. |
+| `telstore config` | Show or change settings. |
+| `telstore token` | Print a session token for a machine you do not trust. |
+| `telstore logout` | Remove the locally stored session. |
 
-## Settings and flags
+## Settings
 
-There are two ways to say what telstore should do, and they never overlap. **`config` writes;
-flags do not.** A flag applies to the run you typed it on and changes nothing on disk, so
-`--to @elsewhere` sends one backup elsewhere without moving the destination for the next one.
+`config` writes; flags do not. A flag applies to the run you typed it on and changes nothing
+on disk, so `--to @elsewhere` sends one backup elsewhere without moving the destination for
+the next one.
 
 ```bash
-npx telstore config                       # everything, and whether it is yours or a default
-npx telstore config chat                  # one value, bare, ready to pipe
-npx telstore config chunkSize 500MB       # change it for good
-npx telstore config chunkSize --unset     # back to the default
+npx telstore config                    # every setting, and whether it is yours or a default
+npx telstore config chunkSize 500MB    # change it for good
+npx telstore config chunkSize --unset  # back to the default
 ```
 
 | Setting | Flag | Default | Meaning |
 |---|---|---|---|
-| `chat` | `--to` | none | `@username`, `-100123…`, or `me`. A negative channel id works with a space or an `=`, as a flag or as a config value. |
-| `chunkSize` | `--chunk-size` | `1800MB` | e.g. `1.8GB`, `500MB`. Hard ceiling 1950MB. An unfinished backup keeps the size it started with. |
-| `uploadConcurrency` | `--upload-concurrency` | `32` | 512KB parts sent in parallel while uploading. An integer from 1 to 64. |
-| `downloadConcurrency` | `--download-concurrency` | `8` | 8MB slices fetched in parallel while restoring. An integer from 1 to 64. |
-| `limit` | `--limit` | `20` | How many backups `list` shows, newest first |
-| `verbose` | `--verbose` | off | Show the Telegram client's own connection logs, hidden by default so they do not break up the progress bar |
-
-`--yes` has no setting either — it answers the confirmation `delete` asks before destroying
-a backup, and an answer stored in a file would be an answer to a question nobody heard.
-
-`--out <path>` has no setting: it names where one particular restore should write, and
-defaults to the basename in the manifest. Relative paths resolve against the current directory.
-
-`config` reads and writes only settings — the `api_id`, `api_hash` and session that `login`
-stores in the same file are not reachable from it. A value is checked before it is written,
-so `config chunkSize 9GB` is refused there and then rather than at the start of a long upload.
+| `chat` | `--to` | none | `@username`, `-100123…`, or `me` |
+| `chunkSize` | `--chunk-size` | `1800MB` | e.g. `1.8GB`, `500MB`. Ceiling 1950MB. |
+| `uploadConcurrency` | `--upload-concurrency` | `32` | 512KB parts in parallel while uploading, 1–64 |
+| `downloadConcurrency` | `--download-concurrency` | `8` | 8MB slices in parallel while restoring, 1–64 |
+| `limit` | `--limit` | `20` | How many backups `list` shows |
+| `verbose` | `--verbose` | off | Show the Telegram client's own connection logs |
+
+Three flags have no setting behind them: `--out <path>` names where one restore writes,
+`--yes` skips the confirmation `delete` asks, and `--token` takes no value — a token written
+on the command line would sit in `ps` and in that machine's shell history, so it is pasted at
+a prompt that does not echo.
 
 ## What the chat looks like
 
-Every chunk goes up as a document captioned `📦 <backupId> · 3/12`, and the manifest that
-follows carries a summary card:
-
-```
-🗄 data.tar
-💾 21.4 GB · 12 chunks
-🆔 telstore-20260905-7f3a91
-📅 2026-09-05 16:40 UTC
-
-↩ npx telstore restore telstore-20260905-7f3a91
-#telstore
-```
-
-`npx telstore list` reads those cards straight out of the chat — one search, no downloads —
-and lays them out as a table:
+Every chunk goes up as a document captioned `📦 <backupId> · 3/12`, followed by a manifest
+carrying a summary card — file name, size, id, date and the restore command. `list` reads
+those cards straight out of the chat, one search and no downloads:
 
 ```
 Destination  https://web.telegram.org/k/#@my_backups
@@ -84,141 +74,50 @@ telstore-20260901-9de447  photos.zip  940.3 MB       1  2026-09-01
 2 backups. Restore with: npx telstore restore <backup-id>
 ```
 
-A backup uploaded before the card existed still gets a row, with dashes where the caption
-says nothing — `list` reports what the chat holds and never fills gaps with guesses.
-
-## How it works
-
-Every run mints a `backupId`. The file is read directly by offset — no temporary copies — and uploaded as documents named `<backupId>.partNNNN`. Once every chunk is up, telstore sends a JSON manifest listing the message id and sha256 of each one. Restore needs only the `backupId`: it finds the manifest in the chat, downloads each chunk to its exact position in a `.partial` file, checks every chunk's sha256 and size, and renames it to the real file only after *all* chunks match.
-
-If the connection drops during an **upload**, just run the same command again — progress lives in `~/.telstore/state/` and finished chunks are skipped, keeping the same `backupId`. Two things to know about rerunning:
-
-- Running again against a destination that differs from the one in the unfinished progress makes telstore **refuse to run** rather than silently redirect — one backup cannot be split across two destinations. The error names the chat to pass as `--to` to carry on, or the state file to delete to start a new backup. It reads the same whether the mismatch came from a flag or from your configured `chat`.
-- Running again **without** `--chunk-size` resumes at the size the backup started with, whatever your configured `chunkSize` says today. A setting is what to use when nobody asks for anything; it is not somebody asking.
-- Running again **with** a `--chunk-size` that differs from that size makes telstore **refuse to run**: the chunks already in the chat were cut that way and cannot be re-cut. Drop the flag to carry on, or delete the state file to start a new backup — which leaves the chunks already sent in the chat with nothing pointing at them.
-
-`Ctrl-C` during an upload names the backup it was working on, so `telstore status` and a later `restore` have something to go on. telstore keeps the **20 most recent** unfinished backups in `~/.telstore/state/`; starting a new one past that drops the oldest record and says which id it dropped. Only the local record goes — the chunks that backup sent stay in the chat, searchable by that id, but it can no longer be resumed.
-
-**Restore keeps no state to resume from.** Pressing `Ctrl-C` mid-restore saves nothing — running again starts over.
-
-## Deleting a backup
-
-```bash
-npx telstore delete telstore-20260905-7f3a91
-```
-
-It prints what it is about to destroy, asks once, and then removes every chunk message and
-the manifest from the chat and drops the local record if there is one. `--yes` skips the
-question. **There is no undo** — Telegram is the only copy.
-
-It also works on a backup that never finished: those have chunks in the chat but no manifest,
-so `list` cannot see them and only `status` knows they exist. `delete` reads the local record
-instead and clears both.
+## Resuming an upload
 
-The chunks go first and the manifest goes last, deliberately. The manifest is the only list
-of the message ids, so if a delete is interrupted — Ctrl-C, a dropped connection — running
-the same command again finds that list still there and finishes the job. Telegram says
-nothing about an id that is already gone, so a second run costs nothing. In between the two
-runs the backup still shows up in `list`, and a `restore` of it fails loudly rather than
-handing over a partial file.
+Progress lives in `~/.telstore/state/` (the 20 most recent), so running the same command
+again skips the finished chunks and keeps the same `backupId`. A resumed backup keeps the
+chunk size it started with; passing a `--chunk-size` or a destination that differs from its
+own makes telstore refuse to run rather than re-cut or redirect it silently.
 
-Two things it refuses rather than guesses at: a manifest whose body names a *different*
-backup (a file renamed in the chat — its message ids point at somebody else's chunks), and a
-manifest or local record giving a message id that is not a whole positive number. Neither
-deletes anything at all. A manifest too damaged for `restore` to use *can* still be deleted —
-that is usually the one you want gone.
+**Restore keeps no state** — `Ctrl-C` mid-restore saves nothing, running again starts over.
+And `delete` has **no undo**: Telegram is the only copy.
 
 ## Running on a machine you do not trust
 
-`login` leaves your Telegram session on the machine you run it on, in plain text. When that
-machine is not yours, print a **session token** on one that is and log in with that instead:
+`login` leaves your session on disk in plain text. When the machine is not yours, print a
+**session token** on one that is and log in with that instead:
 
 ```bash
-# on the machine you are already logged in on
-npx telstore token                        # asks for a passphrase, twice
-                                          # prints one line: tls1.…
-
-# on the other machine
-npx telstore login --token                # paste the token, then type the passphrase
-npx telstore restore telstore-20260905-7f3a91
-npx telstore logout                       # when you are done
+npx telstore token          # on your own machine: asks for a passphrase, prints one line
+npx telstore login --token  # on the other one: paste the token, then the passphrase
+npx telstore logout         # when you are done
 ```
 
 The token holds your `api_id`, `api_hash`, session and settings, encrypted with the
-passphrase (AES-256-GCM, key derived with scrypt). It is one line of base64url, so it
-survives a chat message, an email or a QR code — and a copy that leaks without the
-passphrase is not enough to use your account.
-
-`login --token` stores the token exactly as it arrived, so **the session never exists on that
-machine in a form anyone can read**. Every command that talks to Telegram asks for the
-passphrase and opens it in memory:
-
-```json
-{ "sealed": "tls1.…", "settings": { "chat": "@my_backups" } }
-```
-
-`npx telstore status` shows which of the two you are running:
-
-```
-Session      /home/you/.telstore/config.json (sealed — opened with a passphrase)
-Account      Sho (@shovity)
-Destination  https://web.telegram.org/k/#@my_backups
-Unfinished   none
-```
+passphrase (AES-256-GCM, scrypt), as one line of base64url that survives a chat message or a
+QR code. `login --token` stores it exactly as it arrived and every command asks for the
+passphrase, so the session never exists on that machine in readable form.
 
-### What is left behind
-
-- **No readable session.** `logout` removes the sealed blob, and with it the `api_hash`,
-  which lives inside it.
-- **State files, yes.** An upload writes `~/.telstore/state/<key>.json` so it can be resumed
-  after an interruption. It holds the file path, the chunk sizes and the message ids — no
-  secret — and losing it would strand chunks in the chat with nothing able to name them.
-
-### Things worth knowing before you use one
-
-- **`--token` takes no value, on purpose.** A token written on the command line would sit in
-  `ps` for the whole life of the command and stay in that machine's shell history afterwards.
-  It is pasted at a prompt that does not echo it.
-- **The passphrase may be left empty**, and then the token says so on its face: it starts
-  `tls0.` instead of `tls1.`, `token` warns, and `login` stores the session in plain text
-  exactly as an ordinary login would. telstore will not write a file that looks encrypted and
-  is not.
-- **telstore cannot take a token back.** There is no expiry and no revocation. Like `logout`,
-  it says nothing to Telegram — to end the session for good, open Telegram → Settings →
-  Devices (Active sessions) and terminate it. Every copy of the token dies with it.
-- **A wrong passphrase and a damaged token are the same event** to AES-GCM: one failed
-  authentication check. telstore names both possibilities rather than guessing which it was.
+There is no expiry and no revocation: to end a session for good, terminate it under Telegram
+→ Settings → Devices. An empty passphrase is allowed, and then the token says so on its face
+— it starts `tls0.` and `login` stores the session in plain text.
 
 ## Limits worth knowing
 
-- A chunk cannot exceed 1950MB: Telegram accepts at most 4000 parts of 512KB per file, an arithmetic ceiling of about 1953MB, and telstore stops at 1950MB to leave a safety margin.
-- The data is **not** encrypted. Don't upload anything you would mind sitting on someone else's infrastructure. The one thing telstore does encrypt is a session token, and that protects your login rather than your files.
-- Deleting a chunk message on Telegram destroys the backup, with no way to recover it. Use `npx telstore delete <backup-id>` when that is what you actually want.
-- Keep the `backupId`. Without it you have to hunt for the manifest in the chat by hand.
-
-## Where the config lives
-
-`~/.telstore/config.json` (mode 600) holds `apiId`, `apiHash` and the session at the top level, with everything `config` manages under `settings`:
-
-```json
-{
-  "apiId": 123456,
-  "apiHash": "…",
-  "session": "…",
-  "settings": { "chat": "@my_backups", "chunkSize": 524288000 }
-}
-```
-
-A machine logged in with `npx telstore login --token` holds `sealed` instead of those three
-fields, and nothing else about the account:
-
-```json
-{ "sealed": "tls1.…", "settings": { "chat": "@my_backups" } }
-```
+- **Your data is not encrypted.** Don't upload anything you would mind sitting on someone
+  else's infrastructure — the one thing telstore encrypts is a session token, and that
+  protects your login rather than your files.
+- A chunk cannot exceed 1950MB: Telegram accepts at most 4000 parts of 512KB per file.
+- Deleting a chunk message in the Telegram app destroys the backup, and keeping the
+  `backupId` is what saves you hunting for its manifest in the chat by hand.
 
-A file holding both shapes is refused rather than guessed at — there would be no way to know
-which account was meant.
+Settings and credentials live in `~/.telstore/config.json`, mode 600 — `apiId`, `apiHash` and
+the session at the top level (or a single `sealed` blob after `login --token`), everything
+`config` manages under `settings`. Editing it by hand is fine: a value that cannot be used is
+named on the next run, with the file and the key.
 
-Editing it by hand is fine, and a value that cannot be used is named on the next run — with the file and the key, never with a flag you did not type.
+## License
 
-`npx telstore logout` **only deletes the locally stored session** and keeps the rest — the session is still alive on Telegram's side. To revoke access for good, open Telegram → Settings → Devices (Active sessions) and terminate that session.
+MIT

package/bin/telstore.js

@@ -1,14 +1,10 @@
 #!/usr/bin/env node
 import { route, HELP, interruptMessage } from '../src/cli.js'
-import { runLogin } from '../src/commands/login.js'
-import { runConfig } from '../src/commands/config.js'
-import { runDelete } from '../src/commands/delete.js'
-import { runList } from '../src/commands/list.js'
-import { runLogout } from '../src/commands/logout.js'
-import { runRestore } from '../src/commands/restore.js'
-import { runStatus } from '../src/commands/status.js'
-import { runToken } from '../src/commands/token.js'
-import { runUpload } from '../src/commands/upload.js'
+
+// Each command is imported where it runs, not here. Importing all nine up front pulled
+// teleproto into every invocation — about 0.3s and 45MB — including `--help`, `config` and
+// `logout`, which never open a socket. `src/cli.js` stays a static import because parsing the
+// arguments is the one thing every run does, and nothing it touches reaches the network.
 
 const SIGINT_EXIT_CODE = 130
 
@@ -45,66 +41,97 @@ async function main() {
       process.stdout.write(HELP)
       return
 
-    case 'login':
+    case 'login': {
+      const { runLogin } = await import('../src/commands/login.js')
+
       await runLogin({
         args: parsed.args,
         token: Boolean(parsed.options.token),
         verbose: Boolean(parsed.options.verbose),
       })
       return
+    }
+
+    case 'logout': {
+      const { runLogout } = await import('../src/commands/logout.js')
 
-    case 'logout':
       await runLogout()
       return
+    }
+
+    case 'list': {
+      const { runList } = await import('../src/commands/list.js')
 
-    case 'list':
       await runList(parsed.options)
       return
+    }
+
+    case 'status': {
+      const { runStatus } = await import('../src/commands/status.js')
 
-    case 'status':
       await runStatus(parsed.options)
       return
+    }
+
+    case 'config': {
+      const { runConfig } = await import('../src/commands/config.js')
 
-    case 'config':
       await runConfig(parsed.args, parsed.options)
       return
+    }
+
+    case 'token': {
+      const { runToken } = await import('../src/commands/token.js')
 
-    case 'token':
       await runToken(parsed.args, parsed.options)
       return
+    }
+
+    case 'upload': {
+      const { runUpload } = await import('../src/commands/upload.js')
 
-    case 'upload':
       await runUpload(parsed.args[0], parsed.options, {
         onBackupId: (id) => {
           currentBackupId = id
         },
       })
       return
+    }
 
-    case 'restore':
+    case 'restore': {
       if (!parsed.args[0]) {
         throw new Error('Missing backup id. Example: npx telstore restore telstore-20260905-7f3a91')
       }
+
+      const { runRestore } = await import('../src/commands/restore.js')
+
       await runRestore(parsed.args[0], parsed.options)
       return
+    }
 
-    case 'delete':
+    case 'delete': {
       if (!parsed.args[0]) {
         throw new Error('Missing backup id. Example: npx telstore delete telstore-20260905-7f3a91')
       }
+
+      const { runDelete } = await import('../src/commands/delete.js')
+
       await runDelete(parsed.args[0], parsed.options)
       return
+    }
 
     default:
       throw new Error(`Unknown command: ${parsed.command}`)
   }
 }
 
-// GramJS keeps "exported senders" around together with a 30-second timer to release
-// them, and neither client.disconnect() nor destroy() cleans them up: both of those
-// maps are Maps, but the code walks them with Object.values and so misses everything.
-// The result is a command that prints "Done" and then hangs for another ~30 seconds,
-// during which Ctrl-C falsely reports that nothing was saved. Finish the work, exit.
+// Written for GramJS, which kept "exported senders" alive behind a 30-second release timer
+// that neither disconnect() nor destroy() could clear — both walked a Map with Object.values
+// and missed every entry, so a command printed "Done" and then hung for half a minute, during
+// which Ctrl-C falsely reported that nothing had been saved. teleproto replaced that pool
+// wholesale and closes it on destroy(). This stays anyway: a CLI that has written its last
+// line has nothing left to wait for, and one stray timer in any dependency is all it takes
+// for the wait to come back.
 function exitWhenFlushed(code) {
   // The empty writes exist only to borrow their callbacks: they fire after everything
   // queued earlier has flushed, so nothing is lost when stdout/stderr is not a TTY.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "telstore",
-  "version": "0.1.4",
+  "version": "0.1.6",
   "description": "Split large files into chunks and store them on Telegram",
   "keywords": [
     "telegram",
@@ -37,6 +37,6 @@
     "test": "node --test 'test/**/*.test.js'"
   },
   "dependencies": {
-    "telegram": "^2.26.22"
+    "teleproto": "^1.229.0"
   }
 }

package/src/caption.js

@@ -24,7 +24,7 @@ export function chunkCaption({ id, number, total }) {
 
 export function manifestCaption({ id, name, size, chunks, createdAt }) {
   return [
-    `🗄 ${oneLine(name)}`,
+    `📄 ${oneLine(name)}`,
     `💾 ${formatBytes(size)} · ${chunks} chunk${chunks === 1 ? '' : 's'}`,
     `🆔 ${id}`,
     `📅 ${utcMinutes(createdAt)}`,
@@ -45,7 +45,7 @@ function marker(lines, emoji) {
 export function parseManifestCaption(text) {
   const lines = String(text ?? '').split('\n')
 
-  const name = marker(lines, '🗄')
+  const name = marker(lines, '📄')
   const totals = marker(lines, '💾')
   const id = marker(lines, '🆔')
   const createdAt = marker(lines, '📅')

package/src/client.js

@@ -1,14 +1,14 @@
-import { Api, TelegramClient } from 'telegram'
-import { Logger } from 'telegram/extensions/index.js'
-import { LogLevel } from 'telegram/extensions/Logger.js'
-import { StringSession } from 'telegram/sessions/index.js'
+import { Api, TelegramClient } from 'teleproto'
+import { Logger } from 'teleproto/extensions/index.js'
+import { LogLevel } from 'teleproto/extensions/Logger.js'
+import { StringSession } from 'teleproto/sessions/index.js'
 
 import { manifestFileName } from './manifest.js'
 import { withRetry } from './retry.js'
-import { unlockConfig } from './session.js'
+import { assertLoggedIn, unlockConfig } from './session.js'
 import { DEFAULT_STALL_MS, withStallTimeout } from './stall.js'
 
-// GramJS narrates its version, every connection and every disconnect at info level, and
+// teleproto narrates its version, every connection and every disconnect at info level, and
 // those timestamped lines land in the middle of the progress bar. The client reads this
 // logger before it prints anything, so LogLevel.NONE silences all of it; --verbose asks
 // for the running commentary back when a connection needs diagnosing.
@@ -58,7 +58,7 @@ export async function readMessageBytes(client, message) {
 }
 
 // The one place telstore removes messages from a chat, and the mirror of searchDocuments
-// above. GramJS has its own deleteMessages, and it is the right thing to call — it resolves
+// above. teleproto has its own deleteMessages, and it is the right thing to call — it resolves
 // the peer and picks between channels.DeleteMessages and messages.DeleteMessages, which is
 // exactly the choice a fake client would never catch us getting wrong.
 //
@@ -87,7 +87,7 @@ export async function deleteMessages(client, peer, ids, options = {}) {
 
     await withRetry(
       () =>
-        // The options object is not optional: GramJS destructures `{ revoke }` with no
+        // The options object is not optional: teleproto destructures `{ revoke }` with no
         // default of its own, so a two-argument call throws a TypeError before it ever
         // reaches the network. revoke is passed explicitly anyway — a backup has to go for
         // everyone who can see the chat, and that intent belongs in our code rather than in
@@ -122,18 +122,6 @@ export async function closeQuietly(client, disconnect, onWarn) {
   }
 }
 
-// Two shapes count as logged in: the ordinary one login writes, and the sealed blob that
-// "login --token" leaves, which holds the same three fields behind a passphrase. Checked
-// before anything asks for that passphrase, so somebody who never logged in is told so rather
-// than asked to type a secret for an account that is not there.
-export function assertLoggedIn(config) {
-  if (config.sealed) return
-
-  if (!config.session || !config.apiId || !config.apiHash) {
-    throw new Error('Not logged in — run "npx telstore login" first.')
-  }
-}
-
 // Every command that needs Telegram comes through here, which makes this the one place a
 // sealed session has to be opened. Doing it anywhere else would mean eight places to keep in
 // step, and a ninth command would simply forget.

package/src/commands/delete.js

@@ -1,7 +1,6 @@
 import { chatName, describeChat } from '../chat.js'
 import {
   DELETE_BATCH_SIZE,
-  assertLoggedIn,
   closeQuietly,
   connect as realConnect,
   deleteMessages as realDeleteMessages,
@@ -12,6 +11,7 @@ import { askConfirm } from '../confirm.js'
 import { configFile, defaultConfigDir, loadConfig } from '../config.js'
 import { manifestFileName, manifestMessageIds, parseManifestJson } from '../manifest.js'
 import { formatBytes, formatDuration } from '../progress.js'
+import { assertLoggedIn } from '../session.js'
 import { requireChat, resolveSettings } from '../settings.js'
 import { clearState, findStates } from '../state.js'
 

package/src/commands/list.js

@@ -1,12 +1,12 @@
 import { MANIFEST_TAG, parseManifestCaption } from '../caption.js'
 import { chatName, describeChat } from '../chat.js'
 import {
-  assertLoggedIn,
   closeQuietly,
   connect as realConnect,
   searchDocuments,
 } from '../client.js'
 import { configFile, defaultConfigDir, loadConfig } from '../config.js'
+import { assertLoggedIn } from '../session.js'
 import { requireChat, resolveSettings } from '../settings.js'
 
 const UNKNOWN = '—'

package/src/commands/login.js

@@ -1,5 +1,5 @@
-import { TelegramClient } from 'telegram'
-import { StringSession } from 'telegram/sessions/index.js'
+import { TelegramClient } from 'teleproto'
+import { StringSession } from 'teleproto/sessions/index.js'
 
 import { loadConfig, saveConfig, defaultConfigDir } from '../config.js'
 import { normalizeChatTarget } from '../chat.js'
@@ -26,11 +26,12 @@ export function describeLoginError(err) {
   return `${description} (${message})`
 }
 
-// GramJS starts an update loop the moment a client connects, and that loop only stops when
-// destroy() marks the client destroyed. disconnect() alone leaves it pinging a socket that is
-// already closed: every ping fails with "Error: TIMEOUT" and asks the sender to reconnect,
-// printed straight over the destination question login asks after signing in. Every other
-// command shuts down the same way, and login is the seam tests need to reach it.
+// An update loop starts the moment a client connects, and destroy() is what puts the whole
+// client down — the sender pools included. Under GramJS, disconnect() alone left that loop
+// pinging a closed socket, every ping failing with "Error: TIMEOUT" and asking for a
+// reconnect, printed straight over the destination question login asks after signing in.
+// Every command shuts down through destroy() for that reason, and login is the seam tests
+// need to reach it.
 const createTelegramClient = (apiId, apiHash, options) =>
   new TelegramClient(new StringSession(''), apiId, apiHash, options)
 

package/src/commands/status.js

@@ -1,8 +1,9 @@
 import { countChunks } from '../chunking.js'
 import { describeChat } from '../chat.js'
-import { assertLoggedIn, closeQuietly, connect as realConnect } from '../client.js'
+import { closeQuietly, connect as realConnect } from '../client.js'
 import { configFile, defaultConfigDir, loadConfig } from '../config.js'
 import { formatBytes } from '../progress.js'
+import { assertLoggedIn } from '../session.js'
 import { resolveSettings } from '../settings.js'
 import { canResume, listStates } from '../state.js'
 

package/src/commands/token.js

@@ -1,7 +1,6 @@
-import { assertLoggedIn } from '../client.js'
 import { defaultConfigDir, loadConfig } from '../config.js'
 import { createPrompts } from '../prompt.js'
-import { unlockConfig } from '../session.js'
+import { assertLoggedIn, unlockConfig } from '../session.js'
 import { knownSettings } from '../settings.js'
 import { encodeToken } from '../token.js'
 

package/src/commands/upload.js

@@ -1,8 +1,8 @@
 import { promises as fs } from 'node:fs'
 import path from 'node:path'
 
-import { Api } from 'telegram'
-import { CustomFile } from 'telegram/client/uploads.js'
+import { Api } from 'teleproto'
+import { CustomFile } from 'teleproto/client/uploads.js'
 
 import { PART_SIZE, planChunks } from '../chunking.js'
 import { chunkCaption, manifestCaption } from '../caption.js'

package/src/downloader.js

@@ -2,7 +2,7 @@ import { createHash } from 'node:crypto'
 import { read as readCallback, write as writeCallback } from 'node:fs'
 import { promisify } from 'node:util'
 
-import { returnBigInt } from 'telegram/Helpers.js'
+import { returnBigInt } from 'teleproto/Helpers.js'
 
 import { DEFAULT_DOWNLOAD_CONCURRENCY, PART_SIZE, SLICE_SIZE } from './chunking.js'
 import { withRetry } from './retry.js'
@@ -105,10 +105,14 @@ export async function downloadToFile(
       // Iterated by hand rather than with `for await` so each part can be given a deadline:
       // a stalled stream yields nothing and raises nothing, and only a race against a timer
       // turns that silence into an error withRetry can act on. Nothing is lost by stepping
-      // outside `for await` — GramJS's download iterator exposes `next` alone, so breaking
+      // outside `for await` — teleproto's download iterator exposes `next` alone, so breaking
       // out of the loop never closed anything either.
-      const stream = client.iterDownload({
-        file: message.media,
+      //
+      // The media goes in its own argument, not inside the options: teleproto takes
+      // `iterDownload(file, params)` where GramJS took a single `{ file, ... }` object, and
+      // the options object arriving where the file belongs is not something a fake client
+      // would ever refuse — it fails only against the real one, at getFileInfo.
+      const stream = client.iterDownload(message.media, {
         offset: returnBigInt(start + done),
         requestSize: PART_SIZE,
       })

package/src/retry.js

@@ -10,8 +10,14 @@ function defaultSleep(ms) {
   return new Promise((resolve) => setTimeout(resolve, ms))
 }
 
+// Every "wait this long" answer Telegram gives arrives as code 420 with the seconds on the
+// error itself — FLOOD_WAIT_n, SLOW_MODE_WAIT_n and the rest. Those two fields are what this
+// reads, not how the message is spelled: under GramJS every flood error carried the literal
+// errorMessage "FLOOD", so a check for "FLOOD_WAIT" in it matched nothing and each one was
+// retried on the ordinary backoff — asking again inside a ban that was still running.
+// A 420 with no seconds (a frozen account) has nothing to wait for and takes the backoff.
 function floodWaitSeconds(err) {
-  if (typeof err?.seconds === 'number' && String(err?.errorMessage ?? '').includes('FLOOD_WAIT')) {
+  if (err?.code === 420 && typeof err.seconds === 'number') {
     return err.seconds
   }
   return null

package/src/session.js

@@ -1,7 +1,7 @@
 import { readSecret as realReadSecret } from './prompt.js'
 import { decodeToken } from './token.js'
 
-// How a stored config becomes the three things GramJS needs. There are two shapes on disk —
+// How a stored config becomes the three things teleproto needs. There are two shapes on disk —
 // the ordinary login, and the sealed blob `login --token` writes — and this is the one place
 // that knows the difference, so `connect` stays about Telegram and the commands stay about
 // their own narrative.
@@ -22,3 +22,16 @@ export async function unlockConfig(config, { readSecret = realReadSecret } = {})
 
   return { apiId, apiHash, session }
 }
+
+// Two shapes count as logged in: the ordinary one login writes, and the sealed blob that
+// "login --token" leaves, which holds the same three fields behind a passphrase. It lives
+// here rather than beside connect because knowing both shapes is this file's whole job, and
+// because `token` is an offline command: reaching for it through src/client.js pulled the
+// whole of teleproto into a run that never opens a socket.
+export function assertLoggedIn(config) {
+  if (config.sealed) return
+
+  if (!config.session || !config.apiId || !config.apiHash) {
+    throw new Error('Not logged in — run "npx telstore login" first.')
+  }
+}

package/src/stall.js

@@ -10,16 +10,18 @@ const MAX_TIMER_MS = 2 ** 31 - 1
 // A request that never comes back is not the same as one that fails, and only one of the
 // two is something withRetry can do anything about.
 //
-// GramJS can leave a request queued on a sender it has quietly given up on. Its own abort
-// path is unreachable: MTProtoSender rejects pending states only when
-// `_currentRetries > _reconnectRetries`, and `reconnectRetries` has no default to compare
-// against, so the test is never true (network/MTProtoSender.js:376). Nor does the reconnect
-// itself report failure — `connect()` exhausts its attempts and returns false rather than
-// throwing, so `_reconnect()` finishes as if it had worked and puts the request back on a
-// queue with no send loop left to drain it (network/MTProtoSender.js:148,795).
+// This was written for a GramJS bug that abandoned requests outright: its abort path tested
+// `_currentRetries > _reconnectRetries` against a `reconnectRetries` of Infinity and so never
+// fired, and `_reconnect()` read a `connect()` that merely returned false as success. A real
+// network cut mid-restore froze a transfer for eleven minutes on Linux and ended it without a
+// printed line on Windows. teleproto closes both halves — `connect()` throws once its attempts
+// are spent, and `_reconnect()` catches that and rejects every pending request.
 //
-// The promise then simply sits there. Nothing throws, nothing prints, and once no handle is
-// left the process ends mid-transfer without a word — the one outcome this project forbids.
+// The deadline stays because the library was never the only way to arrive here. A server that
+// accepts a request and answers nothing, a socket that stays open with nothing coming down it:
+// there is no failure for withRetry to see, only silence. The timer is what turns that silence
+// into an error — and, deliberately not unref'd, it is also the handle that stops the event
+// loop running dry and ending a transfer without a word.
 export async function withStallTimeout(promise, ms, describe) {
   if (!(ms > 0)) return await promise
 

package/src/token.js

@@ -46,7 +46,7 @@ function isPlainObject(value) {
 // A token is untrusted input in the same category as a manifest or a state file. Opening one
 // proves whoever made it knew the passphrase, not that they made it correctly — and the
 // unprotected format proves nothing at all. An apiId of undefined does not throw here; it
-// reaches GramJS and fails much later as something that reads like a network problem.
+// reaches teleproto and fails much later as something that reads like a network problem.
 export function checkTokenBundle(bundle) {
   if (!isPlainObject(bundle)) {
     throw new Error(

package/src/uploader.js

@@ -2,8 +2,8 @@ import { createHash, randomBytes } from 'node:crypto'
 import { read as readCallback } from 'node:fs'
 import { promisify } from 'node:util'
 
-import { Api } from 'telegram'
-import { readBigIntFromBuffer } from 'telegram/Helpers.js'
+import { Api } from 'teleproto'
+import { readBigIntFromBuffer } from 'teleproto/Helpers.js'
 
 import { DEFAULT_UPLOAD_CONCURRENCY, PART_SIZE, MAX_PARTS } from './chunking.js'
 import { withRetry } from './retry.js'
@@ -12,8 +12,8 @@ import { DEFAULT_STALL_MS, withStallTimeout } from './stall.js'
 const read = promisify(readCallback)
 
 // Telegram splits its upload API by file size: only files above 10MB may use the
-// "big" family. GramJS picks the same threshold (LARGE_FILE_THRESHOLD in
-// node_modules/telegram/client/uploads.js), and telstore follows it.
+// "big" family. teleproto picks the same threshold (LARGE_FILE_THRESHOLD in
+// node_modules/teleproto/client/uploads.js), and telstore follows it.
 export const LARGE_FILE_THRESHOLD = 10 * 1024 * 1024
 
 async function readExactly(fd, length, position) {
@@ -105,9 +105,9 @@ export async function uploadRange(client, fd, options) {
         sending.push(
           withRetry(
             () =>
-              // Same exposure as the download path: a request left on a sender GramJS has
-              // stopped draining never settles, so without a deadline this await would hold
-              // the batch open forever and the upload would end without a word.
+              // Same exposure as the download path: a request the server accepts and never
+              // answers settles neither way, so without a deadline this await would hold the
+              // batch open forever and the upload would end without a word.
               withStallTimeout(
                 client.invoke(partRequest(part, bytes)),
                 stallMs,