Flitterby

Setup

Connecting an account

Flitterby never asks for a password. Google Drive and Dropbox are connected through their own sign-in screens, and S3-compatible storage through keys you issue yourself and can revoke without involving us.

Google Drive

Source or destination

What to do

Choose Google Drive when adding an account. Google's own sign-in screen opens, you pick the account, and you land back here. There is nothing to configure and nothing to paste.

The permission looks broad, because it is

Google offers one Drive permission and no narrower one that still allows reading the files you pick and writing copies where you ask. We use it for exactly those two things. Google also lets you untick it on that screen: if you do, the connection is refused rather than saved half-working, because a connection that cannot read is not a connection.

You may see an "unverified app" warning

Flitterby is in private testing, and Google shows that warning until an app completes its review. Choose Advanced, then continue. If your address is not on the tester list the sign-in will simply fail, so tell us and we will add it.

Reconnecting every seven days, for now

While the app is in testing Google expires the stored authorization after seven days. Nothing is lost when it happens: the copy parks, you press Reconnect, and it carries on from where it stopped. This goes away when the app is published.

Dropbox

Source or destination

What to do

Choose Dropbox when adding an account and approve it on Dropbox's screen. As with Google, there is nothing to paste.

What we ask for

files.metadata.read files.content.read files.content.write account_info.read sharing.read

Read what you choose, and create what you asked for. There is no delete permission in that list, so a copy into a folder that already holds the same name lands as a new “name (1)” rather than replacing anything.

Team accounts

A Dropbox Business connection can act as any member, so after connecting you pick which member's files to work with. A personal account is only ever itself and the choice does not appear.

S3-compatible storage

Keys, not a sign-in

This one is a form rather than a sign-in, because these providers issue keys instead of using OAuth. Your keys are checked against the live bucket before anything is saved, so a typo is reported immediately rather than at the start of a transfer.

What the form asks for

Name is yours, for telling connections apart. Endpoint is the bucket's S3 URL without the bucket name in it. Bucket is the bucket name on its own. Region can be left as auto where the provider ignores it. Folder prefix is optional and confines Flitterby to one part of the bucket. Then the access key ID and secret access key.

Endpoints and where keys come from

Confirm the endpoint in your provider's own console, since it varies with the region the bucket was created in.

Amazon S3. https://s3.<region>.amazonaws.com, region required. Keys from IAM, under a user's security credentials.

Cloudflare R2. https://<account-id>.r2.cloudflarestorage.com, region auto. Keys from R2, Manage API Tokens, with Object Read and Write.

Backblaze B2. https://s3.<region>.backblazeb2.com, for example s3.us-west-002.backblazeb2.com. Region is the one in the endpoint. Keys from Application Keys.

Wasabi. https://s3.<region>.wasabisys.com. Keys from Access Keys.

DigitalOcean Spaces. https://<region>.digitaloceanspaces.com, for example sfo3.digitaloceanspaces.com. Keys from API, Spaces Keys.

MinIO or self-hosted. Your own URL, and usually us-east-1 unless you set otherwise.

What the key needs to be allowed to do

To read: list the bucket and get objects. To write: put objects, and create, upload and complete multipart uploads for anything large.

It also needs delete, which deserves an explanation given what we say elsewhere. It is used in exactly two places: abandoning a multipart upload of our own that failed partway, and removing a file we had just written whose checksum did not match, so a corrupt copy is not left behind wearing a correct name. It is never used on anything that was already in your bucket. If you would rather it could not, issue a key without delete: transfers still work, and a failed verification leaves the bad object for you to remove.

Your provider may charge for the transfer

Flitterby does not charge for bandwidth, but object storage providers often do, and it is usually billed on the way out, meaning the account you are copying from. Some also charge per request, which scales with how many files you have rather than how large they are, and a few add minimum retention rules. Rates differ by provider and change, so check your provider's pricing before starting a large transfer. See the declaration for the shape of it.

Scoping the key

Every provider here can issue a key limited to one bucket, and most can limit it to a prefix. Doing that is a better protection than anything we can promise you, because it does not depend on us behaving.

When a connection stops working

What it looks like and what to do

Waiting for you to reconnect

The stored authorization stopped being accepted: it expired, or it was revoked, or the account's permissions changed. Use the Reconnect link on the account and resume the copy. It picks up from where it stopped rather than starting over.

Revoking access yourself

Disconnecting here removes the stored credential immediately. You can also revoke Flitterby from Google's or Dropbox's own security settings, or delete the S3 key, which takes effect at once and does not depend on us.

Still stuck

What helps us answer quickly

Write to support@flitterby.com with the provider, the step it failed at, and the exact message. For S3, the endpoint and bucket as you entered them helps most, and never send the secret key.