data-ark 0.1.1 → 0.1.3

package/README.md

@@ -7,6 +7,9 @@ Split large files into 1.8GB chunks, store them on Telegram, and restore them in
 ```bash
 npx data-ark login                        # once only
 npx data-ark data.tar --to @my_backups    # the destination is remembered
+npx data-ark --to @my_backups             # only change the destination, upload nothing
+npx data-ark status                       # account, destination, unfinished backups
+npx data-ark list                         # what is already stored in the destination
 npx data-ark data.tar                     # from the second run on
 npx data-ark restore ark-20260905-7f3a91
 ```
@@ -22,10 +25,46 @@ data-ark signs in with your own Telegram account (MTProto), not a bot. That is a
 
 | Flag | Default | Meaning |
 |---|---|---|
-| `--to <chat>` | the remembered destination | `@username`, `-100123…`, or `me` |
-| `--chunk-size <n>` | `1800MB` | e.g. `1.8GB`, `500MB`. Hard ceiling 1950MB. |
+| `--to <chat>` | the remembered destination | `@username`, `-100123…`, or `me`. `upload` and `status` remember it; `list` and `restore` only look there. A negative channel id works either way: `--to -100123…` or `--to=-100123…` |
+| `--chunk-size <n>` | `1800MB` | e.g. `1.8GB`, `500MB`. Hard ceiling 1950MB. An unfinished backup keeps the size it started with. |
 | `--concurrency <n>` | `8` | 512KB parts sent in parallel. An integer from 1 to 64. |
 | `--out <path>` | the basename from the manifest | Where to write the restored file; relative paths resolve against the current directory |
+| `--limit <n>` | `20` | How many backups `list` shows, newest first |
+| `--verbose` | off | Show the Telegram client's own connection logs, hidden by default so they do not break up the progress bar |
+
+## 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
+🆔 ark-20260905-7f3a91
+📅 2026-09-05 16:40 UTC
+
+↩ npx data-ark restore ark-20260905-7f3a91
+#dataark
+```
+
+`npx data-ark list` reads those cards straight out of the chat — one search, no downloads —
+and lays them out as a table:
+
+```
+Destination  https://web.telegram.org/k/#@my_backups
+
+BACKUP ID            FILE            SIZE  CHUNKS  CREATED
+ark-20260905-7f3a91  data.tar     21.4 GB      12  2026-09-05
+ark-20260901-9de447  photos.zip  940.3 MB       1  2026-09-01
+
+2 backups. Restore with: npx data-ark 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.
+`--to` here only chooses which chat to look at; it does not move the destination the way
+`status --to` does.
 
 ## How it works
 
@@ -34,7 +73,10 @@ Every run mints a `backupId`. The file is read directly by offset — no tempora
 If the connection drops during an **upload**, just run the same command again — progress lives in `~/.data-ark/state/` and finished chunks are skipped, keeping the same `backupId`. Two things to know about rerunning:
 
 - Running again with a `--to` that differs from the destination stored in the unfinished progress makes data-ark **refuse to run** rather than silently redirect — one backup cannot be split across two destinations. The error points the way out: drop `--to` to keep sending to the original destination, or delete the state file to start a new backup.
-- Running again with a different `--chunk-size` is treated as an entirely new backup (new backup id), not a resume.
+- Running again **without** `--chunk-size` resumes at the size the backup started with, whatever the default is today.
+- Running again **with** a `--chunk-size` that differs from that size makes data-ark **refuse to run**, for the same reason as `--to`: 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 `data-ark status` and a later `restore` have something to go on. data-ark keeps the **20 most recent** unfinished backups in `~/.data-ark/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.
 

package/bin/data-ark.js

@@ -1,30 +1,23 @@
 #!/usr/bin/env node
-import { route, HELP } from '../src/cli.js'
+import { route, HELP, interruptMessage } from '../src/cli.js'
 import { runLogin } from '../src/commands/login.js'
+import { runList } from '../src/commands/list.js'
 import { runLogout } from '../src/commands/logout.js'
 import { runRestore } from '../src/commands/restore.js'
+import { runSetDestination } from '../src/commands/set-destination.js'
+import { runStatus } from '../src/commands/status.js'
 import { runUpload } from '../src/commands/upload.js'
 
 const SIGINT_EXIT_CODE = 130
 
 // Which command is running when Ctrl-C arrives — each one tells a different truth
 // about whether progress was saved, so we need to know which to pick the right line.
+// The backup id arrives a moment later, once upload knows which backup this run is.
 let currentCommand = null
-
-function sigintMessage(command) {
-  if (command === 'upload') {
-    return '\nStopped. Progress is saved, run the same command again to continue.\n'
-  }
-
-  if (command === 'restore') {
-    return '\nStopped. Download progress is not saved, running again starts over.\n'
-  }
-
-  return '\nStopped.\n'
-}
+let currentBackupId = null
 
 process.on('SIGINT', () => {
-  process.stderr.write(sigintMessage(currentCommand))
+  process.stderr.write(interruptMessage(currentCommand, { backupId: currentBackupId }))
   process.exit(SIGINT_EXIT_CODE)
 })
 
@@ -47,15 +40,31 @@ async function main() {
       return
 
     case 'login':
-      await runLogin()
+      await runLogin({ verbose: parsed.options.verbose })
       return
 
     case 'logout':
       await runLogout()
       return
 
+    case 'list':
+      await runList(parsed.options)
+      return
+
+    case 'status':
+      await runStatus(parsed.options)
+      return
+
+    case 'set-destination':
+      await runSetDestination(parsed.options)
+      return
+
     case 'upload':
-      await runUpload(parsed.args[0], parsed.options)
+      await runUpload(parsed.args[0], parsed.options, {
+        onBackupId: (id) => {
+          currentBackupId = id
+        },
+      })
       return
 
     case 'restore':

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "data-ark",
-  "version": "0.1.1",
+  "version": "0.1.3",
   "description": "Split large files into chunks and store them on Telegram",
   "keywords": [
     "telegram",

package/src/caption.js

@@ -0,0 +1,63 @@
+import { formatBytes } from './progress.js'
+
+// Captions are plain text on purpose. Telegram would render bold through a parse mode,
+// but that turns every file name into something that has to be escaped correctly, and
+// the fake client the tests talk to would never notice a mistake there.
+
+const DIVIDER = '━'.repeat(15)
+
+// The hashtag is what `list` searches for, and it lives on the manifest alone: chunk
+// captions stay out of that search so a twelve-chunk backup is one hit, not thirteen.
+export const MANIFEST_TAG = '#dataark'
+
+// A file name may legally contain a newline or a tab, and either one would push the
+// rest of the card down a row and take its shape apart.
+function oneLine(name) {
+  return String(name).replace(/\s+/g, ' ').trim()
+}
+
+function utcMinutes(createdAt) {
+  return `${new Date(createdAt).toISOString().slice(0, 16).replace('T', ' ')} UTC`
+}
+
+export function chunkCaption({ id, number, total }) {
+  return `📦 ${id} · ${number}/${total}`
+}
+
+export function manifestCaption({ id, name, size, chunks, createdAt }) {
+  return [
+    `🗄 ${oneLine(name)}`,
+    DIVIDER,
+    `💾 ${formatBytes(size)} · ${chunks} chunk${chunks === 1 ? '' : 's'}`,
+    `🆔 ${id}`,
+    `📅 ${utcMinutes(createdAt)}`,
+    '',
+    `↩ npx data-ark restore ${id}`,
+    MANIFEST_TAG,
+  ].join('\n')
+}
+
+function marker(lines, emoji) {
+  const found = lines.find((line) => line.startsWith(`${emoji} `))
+  return found ? found.slice(emoji.length + 1).trim() : null
+}
+
+// list reads what the chat shows, and a caption is text a person can edit. Anything that
+// does not carry the whole card is reported as unknown rather than half-guessed: a backup
+// listed with invented numbers is worse than one listed with dashes.
+export function parseManifestCaption(text) {
+  const lines = String(text ?? '').split('\n')
+
+  const name = marker(lines, '🗄')
+  const totals = marker(lines, '💾')
+  const id = marker(lines, '🆔')
+  const createdAt = marker(lines, '📅')
+
+  if (!name || !totals || !id || !createdAt) return null
+
+  const match = /^(.+) · (\d+) chunks?$/.exec(totals)
+
+  if (!match) return null
+
+  return { id, name, size: match[1], chunks: Number(match[2]), createdAt }
+}

package/src/chunking.js

@@ -36,6 +36,12 @@ export function parseSize(input) {
   return bytes
 }
 
+// How many chunks a file of this size splits into. planChunks builds them and parseManifest
+// checks them against this same rule, so the layout has one definition, not three.
+export function countChunks(fileSize, chunkSize) {
+  return Math.ceil(fileSize / chunkSize)
+}
+
 export function planChunks(fileSize, chunkSize) {
   if (fileSize <= 0) {
     throw new Error('File is empty, nothing to upload.')

package/src/cli.js

@@ -1,12 +1,14 @@
 import { parseArgs } from 'node:util'
 
-const SUBCOMMANDS = new Set(['login', 'logout', 'restore', 'help'])
+const SUBCOMMANDS = new Set(['login', 'logout', 'list', 'restore', 'status', 'help'])
 
 const OPTIONS = {
   to: { type: 'string' },
   'chunk-size': { type: 'string' },
   concurrency: { type: 'string' },
   out: { type: 'string' },
+  limit: { type: 'string' },
+  verbose: { type: 'boolean' },
   help: { type: 'boolean', short: 'h' },
 }
 
@@ -15,26 +17,86 @@ export const HELP = `data-ark — split large files into chunks and store them o
 Usage:
   npx data-ark login                        Log in to Telegram, only needed once
   npx data-ark <file>                       Split a file and upload it to Telegram
+  npx data-ark list                         List the backups stored in the destination
   npx data-ark restore <backup-id>          Download the chunks and reassemble the file
+  npx data-ark status                       Show the account, the destination and unfinished backups
+  npx data-ark --to <chat>                  Set the destination without uploading anything
   npx data-ark logout                       Remove the saved session
 
 Options:
-  --to <chat>            Destination: @username, -100123..., or me. Remembered for next time.
+  --to <chat>            Destination: @username, -100123..., or me. upload and status
+                         remember it; list and restore only look there.
   --chunk-size <n>       Size of each chunk, default 1800MB. Examples: 1.8GB, 500MB.
+                         An unfinished backup keeps the size it started with.
   --concurrency <n>      512KB parts sent in parallel, default 8, max 64.
   --out <path>           Where to write the restored file. Defaults to the basename in the manifest.
+  --limit <n>            How many backups list shows, default 20.
+  --verbose              Show Telegram connection logs, hidden by default.
   -h, --help             Show this help.
 `
 
+// What Ctrl-C means depends on the command that was running: upload has written every
+// finished chunk to a state file, restore has not. Naming the backup matters because the
+// id is what `status` lists and what a later `restore` needs — the chunks are already in
+// the chat under that id, whether or not this run ever finishes.
+export function interruptMessage(command, { backupId } = {}) {
+  if (command === 'upload') {
+    const backup = backupId ? `Backup ${backupId} is saved` : 'Progress is saved'
+
+    return (
+      `\n${backup} — run the same command again to continue, ` +
+      'or "npx data-ark status" to see what is left.\n'
+    )
+  }
+
+  if (command === 'restore') {
+    return '\nStopped. Download progress is not saved, running again starts over.\n'
+  }
+
+  return '\nStopped.\n'
+}
+
+// A channel id is negative, and typing it separated by a space is the natural reflex —
+// but parseArgs rejects any value starting with a dash as ambiguous. Join the pair itself
+// so `--to -100123` works like `--to=-100123`. Only a bare negative integer qualifies, so
+// `--to --verbose` still reports the missing value instead of eating the next flag, and
+// everything after `--` is left alone because it is no longer an option there.
+function joinNegativeChatId(argv) {
+  const joined = []
+
+  for (let i = 0; i < argv.length; i += 1) {
+    if (argv[i] === '--') {
+      joined.push(...argv.slice(i))
+      return joined
+    }
+
+    if (argv[i] === '--to' && /^-\d+$/.test(argv[i + 1] ?? '')) {
+      joined.push(`--to=${argv[i + 1]}`)
+      i += 1
+      continue
+    }
+
+    joined.push(argv[i])
+  }
+
+  return joined
+}
+
 export function route(argv) {
   const { values, positionals } = parseArgs({
-    args: argv,
+    args: joinNegativeChatId(argv),
     options: OPTIONS,
     allowPositionals: true,
   })
 
   const [first, ...rest] = positionals
 
+  // `data-ark --to @chan` with no file is not a malformed upload, it is someone changing
+  // where the next upload goes. Help would be an unhelpful answer to a clear request.
+  if (first === undefined && values.to && !values.help) {
+    return { command: 'set-destination', args: [], options: values }
+  }
+
   if (values.help || first === undefined || first === 'help') {
     return { command: 'help', args: [], options: values }
   }

package/src/client.js

@@ -1,6 +1,16 @@
-import { TelegramClient } from 'telegram'
+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'
 
+// GramJS 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.
+export function createLogger(verbose) {
+  return new Logger(verbose ? LogLevel.INFO : LogLevel.NONE)
+}
+
 export function normalizeChatTarget(input) {
   const text = String(input).trim()
 
@@ -15,6 +25,71 @@ export function normalizeChatTarget(input) {
   return text
 }
 
+// Telegram's web client addresses a chat by putting the raw target in the fragment, which
+// covers both a negative channel id and an @username. Saved Messages is the exception: it
+// is reached by the account's own id, which data-ark does not know, so it gets no link
+// rather than a guessed one that lands somewhere else.
+export function chatUrl(chat) {
+  const text = String(chat)
+
+  if (text === 'me') return null
+
+  return `https://web.telegram.org/k/#${text}`
+}
+
+// How a destination is spoken about. "me" is a target, not a name someone would recognise
+// in a sentence, so every command that mentions a chat in prose goes through here.
+export function chatName(chat) {
+  return String(chat) === 'me' ? 'Saved Messages' : String(chat)
+}
+
+// A destination is worth more as something clickable than as a raw id, but Saved Messages
+// has no link to give, so it is named instead of being dressed up as one.
+export function describeChat(chat) {
+  const url = chatUrl(chat)
+
+  return url ?? `${chat} (${chatName(chat)})`
+}
+
+// The name Telegram shows under a document lives in an attribute, not on the message.
+export function documentFileName(message) {
+  const attributes = message?.media?.document?.attributes ?? []
+  const named = attributes.find((a) => a instanceof Api.DocumentAttributeFilename)
+  return named?.fileName ?? null
+}
+
+// The one place data-ark searches a chat. Both callers want documents and nothing else,
+// and getMessages is preferred over a raw Api.messages.Search because it handles offsets,
+// hashes and pagination itself, so we don't hand-build easily mistyped fields. The raw
+// message is kept alongside the flat fields because downloading needs it whole.
+export async function searchDocuments(client, peer, { search, limit }) {
+  const messages = await client.getMessages(peer, {
+    search,
+    filter: new Api.InputMessagesFilterDocument(),
+    limit,
+  })
+
+  return messages.map((message) => ({
+    id: message.id,
+    fileName: documentFileName(message),
+    caption: message.message ?? '',
+    date: message.date,
+    message,
+  }))
+}
+
+// Every command ends by putting the connection down, and a failure there must never
+// swallow the real error already on its way up. Commands that print progress hand in an
+// onWarn to say so; the quieter ones let it pass, because a connection that will not
+// close cleanly says nothing about the work that already succeeded.
+export async function closeQuietly(client, disconnect, onWarn) {
+  try {
+    await disconnect(client)
+  } catch (err) {
+    if (onWarn) onWarn(err)
+  }
+}
+
 export function requireChat(options, config) {
   const raw = options.to ?? config.defaultChat
 
@@ -34,12 +109,13 @@ export function assertLoggedIn(config) {
   }
 }
 
-export async function connect(config) {
+export async function connect(config, { verbose = false } = {}) {
   assertLoggedIn(config)
 
   const client = new TelegramClient(new StringSession(config.session), config.apiId, config.apiHash, {
     connectionRetries: 5,
     floodSleepThreshold: 60,
+    baseLogger: createLogger(verbose),
   })
 
   await client.connect()

package/src/commands/list.js

@@ -0,0 +1,136 @@
+import { MANIFEST_TAG, parseManifestCaption } from '../caption.js'
+import {
+  assertLoggedIn,
+  chatName,
+  closeQuietly,
+  connect as realConnect,
+  describeChat,
+  requireChat,
+  searchDocuments,
+} from '../client.js'
+import { defaultConfigDir, loadConfig } from '../config.js'
+
+export const DEFAULT_LIMIT = 20
+
+const UNKNOWN = '—'
+const GAP = '  '
+
+const COLUMNS = [
+  { header: 'BACKUP ID', key: 'id' },
+  { header: 'FILE', key: 'name' },
+  { header: 'SIZE', key: 'size', right: true },
+  { header: 'CHUNKS', key: 'chunks', right: true },
+  { header: 'CREATED', key: 'created' },
+]
+
+// Telegram indexes the tag the manifest caption carries, so one search returns one hit
+// per backup instead of one per chunk. What comes back is still whatever the server
+// decided to match, which is why the caller filters on the file name afterwards.
+async function realSearchManifests(client, peer, limit) {
+  return await searchDocuments(client, peer, { search: MANIFEST_TAG, limit })
+}
+
+function backupIdFromFileName(fileName) {
+  return fileName.replace(/\.manifest\.json$/, '')
+}
+
+function utcDay(unixSeconds) {
+  return new Date(unixSeconds * 1000).toISOString().slice(0, 10)
+}
+
+// The card is text in a chat, which means a person can edit or predate it. The id is the
+// one field restore cannot be wrong about, so it always comes from the file name data-ark
+// wrote; the caption only decorates. A card that cannot be read back leaves the rest
+// unknown, because inventing it would describe a backup that does not exist.
+function toRow(message) {
+  const id = backupIdFromFileName(message.fileName)
+  const card = parseManifestCaption(message.caption)
+
+  if (!card) {
+    return { id, name: UNKNOWN, size: UNKNOWN, chunks: UNKNOWN, created: utcDay(message.date) }
+  }
+
+  return {
+    id,
+    name: card.name,
+    size: card.size,
+    chunks: String(card.chunks),
+    created: card.createdAt.slice(0, 10),
+  }
+}
+
+function renderTable(rows) {
+  const widths = COLUMNS.map((column) =>
+    Math.max(column.header.length, ...rows.map((row) => row[column.key].length)),
+  )
+
+  const line = (cells) =>
+    cells
+      .map((cell, i) => (COLUMNS[i].right ? cell.padStart(widths[i]) : cell.padEnd(widths[i])))
+      .join(GAP)
+      .trimEnd()
+
+  return [
+    line(COLUMNS.map((column) => column.header)),
+    ...rows.map((row) => line(COLUMNS.map((column) => row[column.key]))),
+  ]
+}
+
+function parseLimit(raw) {
+  if (raw === undefined) return DEFAULT_LIMIT
+
+  const limit = Number(raw)
+
+  if (!Number.isInteger(limit) || limit < 1) {
+    throw new Error(`Invalid --limit: "${raw}". Must be a whole number of backups, 1 or more.`)
+  }
+
+  return limit
+}
+
+export async function runList(options = {}, deps = {}) {
+  const {
+    configDir = defaultConfigDir(),
+    connect = realConnect,
+    disconnect = (client) => client.destroy(),
+    searchManifests = realSearchManifests,
+    log = (line) => console.log(line),
+  } = deps
+
+  const limit = parseLimit(options.limit)
+  const config = await loadConfig(configDir)
+  // Ask about the login before the destination: telling someone who has never logged in
+  // to pick a chat sends them off after the wrong thing.
+  assertLoggedIn(config)
+  // Unlike status, --to here means "look over there", not "send there from now on":
+  // listing another chat should not quietly redirect the next upload.
+  const chat = requireChat(options, config)
+
+  const client = await connect(config, { verbose: options.verbose })
+
+  let found
+  try {
+    found = await searchManifests(client, chat, limit)
+  } finally {
+    await closeQuietly(client, disconnect)
+  }
+
+  log(`Destination  ${describeChat(chat)}`)
+  log('')
+
+  const rows = found
+    .filter((message) => message.fileName?.endsWith('.manifest.json'))
+    .map(toRow)
+
+  if (rows.length === 0) {
+    log(`No backups found in ${chatName(chat)}. Upload one with: npx data-ark <file>`)
+    return rows
+  }
+
+  for (const line of renderTable(rows)) log(line)
+
+  log('')
+  log(`${rows.length} backup${rows.length === 1 ? '' : 's'}. Restore with: npx data-ark restore <backup-id>`)
+
+  return rows
+}

package/src/commands/login.js

@@ -5,7 +5,7 @@ import { TelegramClient } from 'telegram'
 import { StringSession } from 'telegram/sessions/index.js'
 
 import { loadConfig, saveConfig, defaultConfigDir } from '../config.js'
-import { normalizeChatTarget } from '../client.js'
+import { createLogger, normalizeChatTarget } from '../client.js'
 
 function createPrompts() {
   const rl = readline.createInterface({ input: stdin, output: stdout })
@@ -33,10 +33,25 @@ export function describeLoginError(err) {
   return `${description} (${message})`
 }
 
-export async function runLogin({ configDir = defaultConfigDir(), prompts = createPrompts() } = {}) {
+// 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.
+const createTelegramClient = (apiId, apiHash, options) =>
+  new TelegramClient(new StringSession(''), apiId, apiHash, options)
+
+export async function runLogin({
+  configDir = defaultConfigDir(),
+  prompts = createPrompts(),
+  verbose = false,
+  createClient = createTelegramClient,
+  shutdown = (client) => client.destroy(),
+  log = (line) => console.log(line),
+} = {}) {
   const config = await loadConfig(configDir)
 
-  console.log('You need your own api_id and api_hash. Get them at https://my.telegram.org → API development tools.\n')
+  log('You need your own api_id and api_hash. Get them at https://my.telegram.org → API development tools.\n')
 
   const apiIdAnswer = (await prompts.ask(`api_id${config.apiId ? ` [${config.apiId}]` : ''}: `)).trim()
 
@@ -53,7 +68,10 @@ export async function runLogin({ configDir = defaultConfigDir(), prompts = creat
     throw new Error('Missing api_id or api_hash.')
   }
 
-  const client = new TelegramClient(new StringSession(''), apiId, apiHash, { connectionRetries: 5 })
+  const client = createClient(apiId, apiHash, {
+    connectionRetries: 5,
+    baseLogger: createLogger(verbose),
+  })
 
   await client.start({
     phoneNumber: () => prompts.ask('Phone number (e.g. +1...): '),
@@ -64,7 +82,7 @@ export async function runLogin({ configDir = defaultConfigDir(), prompts = creat
 
   const me = await client.getMe()
   const session = client.session.save()
-  await client.disconnect()
+  await shutdown(client)
 
   const chatAnswer = (
     await prompts.ask(
@@ -82,6 +100,6 @@ export async function runLogin({ configDir = defaultConfigDir(), prompts = creat
 
   await saveConfig(next, configDir)
 
-  console.log(`\nLogged in as ${me.username ? `@${me.username}` : me.firstName}.`)
-  console.log(`Config saved to ${configDir}/config.json`)
+  log(`\nLogged in as ${me.username ? `@${me.username}` : me.firstName}.`)
+  log(`Config saved to ${configDir}/config.json`)
 }