next #2
Loading…
Reference in a new issue
No description provided.
Delete branch "next"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Binks 0.9 answers every error with a documented code ("Act on code; messages may change"), and 0.8's status field is gone. The CLI now keeps the code, decides on it instead of statuses and messages, and words the common ones for the command line: a taken ID points at --id, a rate limit or a busy server says when to try again, and the rest show the server's message, which says what to do ("The file is too large: at most 100 MB"). Two hints need what only the CLI knows: an anonymous request refused with sign_in_required points at `binks login`, and a request refused with unauthorized while it carried an API token (an expired or revoked one, which 0.9 refuses instead of treating as anonymous) says to get a new one. A wrong two-factor code at sign-in is said in plain words. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>0.8's CLI guessed what an ID named: a paste, and on a 404 a file. Binks 0.9 says it in the item's metadata (GET /api/items/{id}), which never counts as a read or burns anything, so `binks get` asks for it first, and a password, a scan or a used-up item stops it before a read is spent. Then by kind: a text prints from /{id}/raw; a file's note prints (it never counts) before the file downloads from /{id}/file, resuming with Range as before; a link prints its target from the metadata, without a read. A burn-after-reading link leaves its target out of the metadata, since showing it is a read, so get reads it from /{id}/raw and says it used one up; reads of burn-after-reading items say how many are left. `--info` shows the metadata (the server's item JSON with --json) and never burns. What keeps an item from being read is told by its code: being scanned (423, with `--wait` waiting out its Retry-After), held for review, removed, expired or burned. On a terminal, text that doesn't end in a newline gets one, so the prompt and status lines start on their own line; piped, the bytes stay as they are. The tests read the server through the items API too, as 0.8's routes go in step 10. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>Binks 0.9 deletes with DELETE /api/items/{id}, by the owner's token or the item's X-Deletion-Token, and keeps the account's routes under /api/me; 0.8's /api/paste and /api/user/tokens go in step 10. With this the CLI calls none of 0.8's routes. The refusals are told apart by their code: no credentials (sign in or pass --deletion-token), credentials that no longer hold (an expired or revoked API token, refused rather than taken as anonymous), and a wrong deletion token or someone else's item, with the server's reason. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>