FluxDrive: Self-Service API Keys, Now With Scopes

Fluxers! FluxDrive — decentralized storage on Flux — has had a solid month of work aimed squarely at one thing: making it something you can build against, not just upload to. Self-service API keys, per-key permissions, folder paths on the API, and a set of fixes to the parts that only break at scale.

Create your own API keys

You can now manage API keys yourself from the FluxDrive web interface. No ticket, no waiting. Create a key, use it, revoke it.

That alone unblocks the obvious things — a backup script, a CI job that publishes build artefacts, an application that stores user uploads on Flux instead of on a centralised bucket.

Granular per-key scopes

A key that can do everything is a key you cannot safely put anywhere. So keys now carry granular scopes, chosen per key:

• read — fetch file contents
• list — enumerate folders
• write — upload and update
• delete — remove

The pattern you want is the obvious one: give the backup job write but not delete, give the public read path read but not list, and keep a single administrative key for yourself. A leaked key is then a nuisance rather than a catastrophe.

Scopes are documented in full on the Flux documentation site, and the API key guide now has screenshots of the flow.

Folder paths, not just UUIDs

A folder can now be listed by its path, not only by its UUID. If you have ever tried to script against an API that requires you to resolve an opaque identifier before you can ask a question, you will know exactly why this matters. Your script can now say what it means.

Related, and just as practical: the listing endpoint now accepts includeFolders from form-encoded callers as well as JSON ones, which was silently ignoring the flag for a whole class of client.

Three bugs worth naming

These are the kind that are invisible until the moment they are not.

An upload could delete an unrelated file with identical content. Content-addressed storage deduplicates by hash, which is what you want for efficiency — but the bookkeeping around it meant that uploading a file whose bytes matched an existing one could remove the other reference. Fixed.

Deep pagination failed on large folders. If your folder was small you never saw it. If it was large, paging past a certain depth stopped working. Fixed.

Renewals could wipe your API keys. A FluxPay or crypto.com subscription renewal was clearing the user’s keys as a side effect — which is exactly the sort of thing that only shows up a month after you have wired everything to a key. Fixed, and worth checking your integrations if you renewed recently.

Two more: files uploaded through the API are now visible in the web interface (they were being written correctly but not surfaced), and an IPFS folder name collision now reports itself as a collision instead of a generic 500.

Repair that can be undone

On the operations side, the backfill tooling now journals every change and supports undoing a run, and repairs by folder group rather than file by file. A storage repair job you cannot reverse is a storage repair job you are afraid to run, which means it does not get run, which means the problem stays.

Also fixed: the private-network flag for the IPFS daemon is now actually applied, which it was not before.

Try it

Go to FluxDrive, create a key with only the scopes you need, and point something at it. The API reference on the docs site has been corrected against the implementation — where the documentation and the code disagreed, the documentation lost.