todo: the SendOff size limit should be per user, from settings

512 MB was chosen as enough-for-now on the day the feature landed, and it applies
to every account equally. The owner asked for it per user before the code was an
hour old.

Notes the adjacent question while it is in view: a size limit bounds one send, and
nothing bounds what a sender accumulates in somebody's tree over a month.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

todo/sendoff/_index.md

@@ -0,0 +1,8 @@
+---
+theme: sendoff
+heading: 'SendOff'
+kind: theme
+---
+
+Sending files to your own machines, and to accounts that have allowed you. Landed 2026-08-23 as a folder
+convention plus one endpoint — `docs/sendoff.md` is the design, `src/servers/api/sendoff/` the code.

todo/sendoff/per-user-size-limit.md

@@ -0,0 +1,30 @@
+---
+id: sendoff/per-user-size-limit
+title: 'The SendOff file size limit is one constant for everybody'
+theme: sendoff
+status: open
+created: 2026-08-23
+date_source: stated
+order: 1
+---
+
+**`MAX_FILE_SIZE` in `src/servers/api/sendoff/router.ts` is a hard-coded 512 MB and applies to every
+account equally.** The owner asked for it to be configurable per user, from settings, on the day the
+feature landed — 512 MB was chosen as "enough for now" rather than as a considered ceiling.
+
+Why it wants to be per-user rather than one server-wide number: the accounts differ in what they are for.
+The owner sending themselves a video off a phone and a member being allowed to drop a document are not the
+same size of thing, and the honest limit for one is an insult or a hazard for the other. A single number
+has to be set for the most generous case, which is exactly the case you would want to bound.
+
+Shape, when it is built:
+
+- An owner-only setting, per account, defaulting to the current 512 MB when unset. Absence means default,
+  not unlimited — the same posture the permission model already takes.
+- Enforced in `POST /sendoff/send` where the constant is read today, so there is one place it can be wrong.
+- The refusal has to say the limit it applied. A 400 reading "too big" against an invisible per-account
+  number is the kind of error somebody retries three times before asking.
+
+Worth deciding at the same time, because it is the same question one layer out: whether a **disk quota**
+belongs here too. A size limit bounds one send; nothing currently bounds how much a sender may accumulate
+in somebody's tree over a month, and the recipient's only tool is revoking them afterwards.