infosec.exchange
infosec.exchange · Storage · 1 record · JSON
infosec.exchange — Mastodon with a 1.35 GiB per-file upload limit (highest single-object cap found anywhere in the fediverse) Storage
fails: quotainstitutionno cardRper-object-cap
| Free tier | Per-account storage is UNLIMITED (stock Mastodon has no per-user media quota at all — media_attachment has only a per-file size validator, no account-level counter). Per FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB. That is a 84x relaxation of Mastodon's compiled defaults (IMAGE_LIMIT 16 MB / VIDEO_LIMIT 99 MB). unit GiB; metered on stored-bytes |
|---|---|
| Price | none stated |
| Per-object cap | Per FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB (1417339207 bytes) |
| Retention | infosec.exchange is one of the largest and best-funded Mastodon instances (Glitch fork 4.8.0-alpha.3) and explicitly runs a relaxed upload policy; still a single volunteer operator, and a 1.3 GiB upload is exactly the kind of thing that gets noticed. Media is permanent by Mastodon semantics (no TTL, no GC), which cuts both ways. |
| Egress | Free. No egress meter on the instance; media sits behind the instance CDN (often S3/Wasabi/B2-compatible behind a CNAME). |
| Identity | institution derived from the record's prose, not from an identity field, and no signup was executed: hments per status, one status carries 10.6 GiB in a single API call chain. Multiple accounts on the same instance each get the same unlimited-account treatment. Multiply over instanc |
| Limits |
request-rate is THE binding limit, and it is severe: stock Mastodon rack_attack ships throttle('throttle_api_media', limit: 30, period: 30.minutes) per authenticated user — 30 media uploads per half hour = 1,440/day. At 1.32 GiB each that is a theoretical 1.9 TB/day/account, so realistically you hit GB-scale throughput only by running many accounts in parallel. Also: 8 media per status (MAX_MEDIA_ATTACHMENTS), 4 statuses/30 min soft on some instances, MAX_VIDEO_FRAMES 36,000 (≈5 min at 120 fps) and MAX_VIDEO_MATRIX_LIMIT 8,294,400 px cap video dimensions, and non-image/video MIME types are rejected by the upload validator. |
| Binding | per-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota |
| Interface | rest, rclone, cli rest |
| Tooling | Mastodon REST API v1: POST /api/v1/media (multipart file -> returns media id + url), then POST /api/v1/statuses with media_ids[] to make it permanent. OAuth2 app registration via POST /api/v1/apps (no manual approval on most instances). Any of the many existing clients work; toot CLI, Mastodon.py. Upload-from-URL: POST /api/v2/media with url param. rclone has no Mastodon backend but the API is 3 calls. |
| Composes with | The key structural fact: NO per-account quota means the ceiling is the instance's disk, and the operator absorbs it. Combined with a 1.32 GiB per-file cap and 8 attachments per status, one status carries 10.6 GiB in a single API call chain. Multiple accounts on the same instance each get the same unlimited-account treatment. Multiply over instances for isolation. |
| Reliability | infosec.exchange is one of the largest and best-funded Mastodon instances (Glitch fork 4.8.0-alpha.3) and explicitly runs a relaxed upload policy; still a single volunteer operator, and a 1.3 GiB upload is exactly the kind of thing that gets noticed. Media is permanent by Mastodon semantics (no TTL, no GC), which cuts both ways. |
| Notes | Per-account storage is UNLIMITED (stock Mastodon has no per-user media quota at all — media_attachment has only a per-file size validator, no account-level counter). Per FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB. That is a 84x relaxation of Mastodon's compiled defaults (IMAGE_LIMIT 16 MB / VIDEO_LIMIT 99 MB). |
| Evidence rung | reported One page read moves it to documented. |
| Checked | 2026-10-21 (inherited); stale on 2026-11-04 |
| Parsed numbers |
|
Evidence (4)
| date | source | what it proved |
|---|---|---|
| 2026-10-21 | infosec.exchange/api/v2/instance | probe: GET -> 200, configuration.media_attachments.image_size_limit=1419430400, video_size_limit=1419430400, registrations.enabled=true |
| 2026-10-21 | infosec.exchange/api/v1/instance | probe: GET -> 200, max_toot_chars=11000, registrations=true |
| 2026-10-21 | raw.githubusercontent.com/mastodon/mastodon/main/app/models/ | IMAGE_LIMIT = 16.megabytes, VIDEO_LIMIT = 99.megabytes, validates_attachment_size :file, less_than: ... — confirms the cap is a per-file validator with NO per-account quota anywhere in the model |
| 2026-10-21 | raw.githubusercontent.com/mastodon/mastodon/main/config/init | throttle('throttle_api_media', limit: 30, period: 30.minutes) { |req| req.authenticated_user_id if req.post? && req.path.match?(%r{\A/api/v\d+/media\z}i) } |
More fields (2)
{
"verdict_note": "PLAN.md §3.2 rules fails-quota by default, because no row in this set clears 500 GiB per unit for a user.",
"dead_end": {
"failure_class": "quota",
"why": "Per-account storage is UNLIMITED (stock Mastodon has no per-user media quota at all — media_attachment has only a per-file size validator, no account-level counter). Per FILE: image_size_limit = video_size_limit = 1419430400 bytes = 1.32 GiB. That is a 84x relaxation of Mastodon's compiled defaults (IMAGE_LIMIT 16 MB / VIDEO_LIMIT 99 MB).",
"retry_when": null,
"first_recorded": "2026-10-21"
}
}Unknown or withheld values (4)
$.extras.dead_end.retry_whenprocess$.free_tier.notesprocess$.per_object_cap.notesnot-extracted$.retention.notesnot-extracted