- Free allowance
- 1024000 MB = 1 TiB drive capacity PER USER.
- Verdict
- caveatusable, with a named limit or an unprobed read path
- Cost
- free tier
- Identity
- institution?placeholder, not evidence; card unknown, phone unknown
- Binding limit
- per-object-cap250 MiB per object (top-level maxFileSize 262,144,000 bytes); policies.maxFileSizeMb claims 1 GiB and is not enforced
- Evidence
- documented5 sources; a first-party page was read and the sentence quoted
- Freshness
- stale on 2026-11-21checked 2026-10-21 (inherited); stale on 2026-11-21
| Free tier | 1024000 MB = 1 TiB drive capacity PER USER. The per-object cap is 250 MiB: maxFileSizeMb reads 1024 (1 GiB) but the top-level maxFileSize of 262,144,000 bytes is the enforced field. This is the single largest per-user quota located on a live, registration-open fediverse instance. unit TiB; metered on unstated |
|---|
| Price | none stated |
|---|
| Limits | - per-object-cap (binding) 250 MiB per object (top-level maxFileSize 262,144,000 bytes); policies.maxFileSizeMb claims 1 GiB and is not enforced source
- write-gated inviteLimit: 1` per 1440 min does NOT gate open signup source
per-object-cap 1 GiB (maxFileSizeMb=1024, verified 262144000 bytes = 250 MiB on most other instances, 524288000 = 500 MiB on misskey.io). Drive quota 1 TiB/user. Usage-anomaly controls: inviteLimit: 1 per 1440 min does NOT gate open signup. Request-rate: Misskey applies a per-IP rate limiter on /api/drive/files/create (4096 req/hr default per IP, plus per-account limits, 250 MB/hr-ish effective on small instances). |
|---|
| Identity | institution (inferred, not read) not published |
|---|
| Egress | Free. Media is served from a plain path on the instance domain (observed scheme: https://sss.<instance>/sss/<shard>/<uuid>) with Cache-Control: max-age=31536000, immutable. No egress meter, no bandwidth charge, no signed URL. |
|---|
| Per-object cap | 250 MiB per object, enforced by the top-level maxFileSize of 262,144,000 bytes (262144000 bytes) |
|---|
| Retention | not stated |
|---|
| Interface | rest, rclone rest |
|---|
| Tooling | Misskey HTTP API is a clean JSON REST surface: POST /api/drive/files/create (multipart, file field) with an i (token) in the body; POST /api/drive/files/upload-from-url; POST /api/drive/files/delete; POST /api/drive/files (list). Token minted via MiAuth (GET https://<host>/miauth/<uuid>?name=...&permission=write:drive,read:drive) or POST /api/signin with username+password -> returns i, which is then just a query param. No library needed: it is a 20-line requests wrapper. rclone has no Misskey backend; write a thin one. |
|---|
| Composes with | driveCapacityMb is a per-user soft counter enforced by the instance, not a hard technical wall — media attached to notes can still be served after the drive is full. Because each account is an independent counter and registration is open (API reports disableRegistration: false, emailRequiredForSignup: true), each account holds 1 TiB. Ten accounts hold 10 TiB. The provider accepts a single POST per account, so a client with mail control can register many. |
|---|
| Reliability | Instance is a single volunteer-run host with ~small user count; a 1 TB drive is a published number, not a promise, and one operator decision or a disk-full incident takes everything offline at once. No SLA, no backup guarantee. Treat as 'high capacity, zero durability'. |
|---|
| Notes | 1024000 MB = 1 TiB drive capacity PER USER, with a 250 MiB per-object cap: maxFileSizeMb reads 1024 (1 GiB) and the top-level maxFileSize of 262,144,000 bytes is enforced, so a 1 TiB drive at 250 MiB per object needs 4,096 uploads. This is the single largest per-user quota located on a live, registration-open fediverse instance. |
|---|
| Evidence note | documented The quota is a live API field read, not a page claim. The record stays documented because the identity field is inferred from prose, not read from the API. Was documented; now documented. |
|---|
| Parsed numbers | - has-free-tier 1
- per-object-cap 250 MiB
|
|---|