Per-account quota: decide the figure after global photo processing (10 GB stopgap since 09.09.2026)

[Devski]

Opened 09.09.2026 (Dawid, in conversation). The per-account quota (A9) went from 1 GB to 10 GB the same day, in one constant (QUOTA_BYTES in src/lib/quota.ts), because the first real orbit archive could not be uploaded on dev: 1.8 GB of PNG frames, which a zip cannot shrink, against a 1 GB account. Dawid wants uploads of that kind allowed. 10 GB is a stopgap figure, not a decision about the product; this issue is where the figure gets decided.

When

After photo processing is global (#71, imgproxy or its alternative) and after #69 has narrowed the counted number to the largest kept representation of every asset, with the R360 archive out of the sum as SPEC A12/A13 already say. Both change what a gigabyte of quota buys, so the figure is set after them, not before.

What to decide

• The free quota per account, and whether the R360 archive stays outside it (SPEC §10, "A free 10 GB for everyone"; the archive row "to revisit with the paid-model conversation").
• The pain threshold in §10: at 10 GB it is ~1,000 full accounts for ~€75/month (OVHcloud, zero egress). Recompute with the real figure and the real share of accounts that fill up.
• Whether ARCHIVE_MAX_BYTES (5 GB, the single CopyObject limit on AWS) still bounds the archive correctly on OVHcloud now that an archive that size fits the quota. Dawid's 1.8 GB trial exercises a copy above 1 GB on the real bucket; the 5 GB edge stays unverified (comment in src/lib/archive-upload.ts).

What the change of 09.09.2026 touched

QUOTA_BYTES, the two "quota exceeded" messages in pl/en, the e2e text, SPEC A9 and the §10 row, the frame-set quota test (which now fills the account to leave room for two 360-frame sets instead of relying on three sets passing 1 GB).

Spec: SPEC.md A9, A12, A13, §10 · Related: #69, #71, #30 · Label: decision, enhancement

[Devski]

Zero egress verified at the source, 09.09.2026

Checked because the whole "a free quota is safe" argument in SPEC §10 rests on it. Not from
marketing copy — from OVHcloud's own order catalogue, which is the table the invoice is
computed from (https://api.ovh.com/v1/order/catalog/public/cloud?ovhSubsidiary=FR, EUR, ex VAT):

Catalogue plan code	Price
bandwidth_storage-standard_out.consumption	0
storage-api-call.consumption	0
bandwidth_instance_out.consumption (and .3AZ)	0
storage-standard.consumption (One-Zone)	€0.0071 / GiB / month
storage-standard-3AZ.consumption	€0.01399 → €0.01099 / GiB / month, tiered

The public price list carries the same sentence under every Object Storage class: outgoing
traffic is free for all customers, with one carve-out — customers contracted with the APAC
entities (India, Singapore, Asia USD, Australia) keep it free only until 31 December 2026.
Both our regions are European, so the carve-out does not reach us. The only egress rate that
is not zero anywhere in the catalogue is bandwidth_instance_out.consumption.SGP1 / .SYD1
at €0.01/GiB.

So the figures in SPEC §10 hold, and the storage rate is slightly better than the cost model
assumed (€0.0071 against €0.0075). Egress is not a cost dimension of this product. What is
left is a throughput limit, not a price: the Object Storage FAQ states bandwidth is shared
and not guaranteed, at most 1 Gbps per connection.

The figure this issue has to decide is bounded by A12, not by money

Storage is cheap enough that cost does not pick the number. At 1,000 accounts filled to the
brim: 10 GiB → €71/month One-Zone, 25 GiB → €178, 50 GiB → €355 (roughly double on 3-AZ).
Realistic fill of 20% divides all of it by five.

What does pick the number is that 10 GB is less than a profile is allowed to hold. A12
permits ten works per profile and an R360 archive of any size on each. Counting the ceilings
the reservation actually charges (R360_FRAME_MAX_BYTES: 1 MiB + 384 KiB per frame):

Contents of a maxed profile	Archive counted	Archive excluded
10 works × 120-frame R360 × 1.8 GB archive	18.4 GiB	1.6 GiB
10 works × 360-frame R360 × 1.8 GB archive	21.6 GiB	4.8 GiB

A single work at 360 frames reserves 0.48 GiB of frames on top of its 1.68 GiB archive. So an
account today can publish four or five R360 works and then hit a wall the interface promised
it ten of.

And the archive is counted right now, despite SPEC §10 saying it sits outside the A9 limit
— archiveUploadConfirm calls quotaAllows(db, userId, head.sizeBytes) in
src/lib/archive-upload.ts:169. The spec describes where #69 is going; the code has not gone
there yet. Worth saying out loud, because that gap is exactly what the 1.8 GB upload hit.

That makes the decision a fork rather than a dial:

• Archive stays in the sum → the quota has to clear ~25 GB for A12's ten works to be real.
  €178/month per 1,000 completely full accounts, and archives are then ~92% of the bill.
• Archive leaves the sum (Storage meter per account: count the largest representation of every asset, show the usage #69, what SPEC already claims) → 10 GB is already 2× a maxed
  profile, and the ten-works cap is what bounds storage. Archive storage becomes an unmetered
  liability bounded only by works × accounts, which is the thing the paid-model conversation
  has to price.

Either way the archives, not the frames and not the traffic, are the entire future bill: they
outweigh the frames they produce by roughly 11:1 at 360 frames and 35:1 at 120, and they are
kept only to keep a server-side re-encode possible later.